(copilot workspace) update_umbraco_content / set_umbraco_content_value report success incorrectly

[ThomCogworks]

Which component is this issue related to?

Umbraco.AI (Core)

Which Umbraco AI version are you using? (Please write the exact version, example: 10.1.0)

17.4.0-rc.4

Bug summary

update_umbraco_content and set_umbraco_content_value both report success: true when writing to certain non-text property editors, but the value is silently coerced back to its empty/default state — sometimes visible in the very same response that reported success.

Specifics

I think this is a different bug from the one fixed in #349 / ContentPropertyValueOperationHelper (rc.4) — that fix addressed other properties getting wiped when one is touched; this is about the targeted property itself failing to persist its new value, even alone.

update_umbraco_content and set_umbraco_content_value both report success: true when writing to certain non-text property editors, but the value is silently coerced back to its empty/default state — sometimes visible in the very same response that reported success.

Confirmed on Umbraco.TrueFalse (boolean toggle) with a full request/response trace below, and also observed (not yet traced in the same detail) on a content picker (Umbraco.MultiNodeTreePicker) property. A plain Umbraco.TextBox property on the same document, via the same tool call pattern, persists correctly — so this looks isolated to specific editor/value types rather than the document or the tool call plumbing in general.

Examples given below in steps to reproduce.

Environment

• Umbraco.AI: 17.4.0-rc.4
• Umbraco.AI.Agent: 17.2.0-rc.4
• Umbraco.AI.Agent.Copilot: 17.1.0-rc.4
• Umbraco.AI.Agent.Copilot.Workspace: 17.0.0-rc.4
• Umbraco.AI.Agent.UI: 17.1.0-rc.4
• Umbraco.Cms: 17.7.0
• Provider: Anthropic, model claude-sonnet-5

Since the returned content in Attempt 1/2 already shows the coerced-back 0 in the same response that reports success: true, this doesn't look like an async persistence or stale-read issue — the value appears to be getting reset (or never correctly converted) during the save itself, before the response is even built. Given both a JSON boolean and a JSON integer failed identically, and a plain string-valued TextBox property succeeds, this smells like a value-conversion step between the AI tool's incoming PropertyValueModel.Value (a JsonElement) and whatever TrueFalsePropertyEditor's (and possibly MultiNodeTreePicker's) IDataValueEditor.FromEditor expects — as if a type mismatch is being silently swallowed and falling back to a default/empty value instead of erroring.

Steps to reproduce

Content type personPage, document key 6cce0498-da64-488e-9959-5ba5beecf39a, data type key 92897bc6-a5f3-4ffe-ae27-f2e7e33dda49. Affected properties: excludeFromBreadcrumb, excludeFromNavigation, excludeFromSearch — all Umbraco.TrueFalse.

Attempt 1 — update_umbraco_content, all three toggles at once

Request:

{
  "tool": "update_umbraco_content",
  "key": "6cce0498-da64-488e-9959-5ba5beecf39a",
  "name": null,
  "propertyValues": {
    "excludeFromBreadcrumb": true,
    "excludeFromNavigation": true,
    "excludeFromSearch": true
  }
}

Response (the returned content already shows 0, not 1, in the same response that reports success):

{
  "success": true,
  "content": {
    "properties": [
      { "alias": "excludeFromBreadcrumb", "editorAlias": "Umbraco.TrueFalse", "value": 0 },
      { "alias": "excludeFromNavigation", "editorAlias": "Umbraco.TrueFalse", "value": 0 },
      { "alias": "excludeFromSearch", "editorAlias": "Umbraco.TrueFalse", "value": 0 }
    ]
  }
}

Attempt 2 — update_umbraco_content, single toggle

Request:

{
  "tool": "update_umbraco_content",
  "key": "6cce0498-da64-488e-9959-5ba5beecf39a",
  "name": null,
  "propertyValues": { "excludeFromBreadcrumb": true }
}

Same result — response echoes "value": 0 immediately.

Attempt 3 — set_umbraco_content_value, JSON boolean true

Request:

{
  "tool": "set_umbraco_content_value",
  "key": "6cce0498-da64-488e-9959-5ba5beecf39a",
  "path": [{ "alias": "excludeFromBreadcrumb", "blockKey": null }],
  "value": true
}

Response: { "success": true }

Follow-up get_umbraco_content immediately after:

{ "alias": "excludeFromBreadcrumb", "editorAlias": "Umbraco.TrueFalse", "value": false }

Attempt 4 — set_umbraco_content_value, JSON integer 1

Request:

{
  "tool": "set_umbraco_content_value",
  "key": "6cce0498-da64-488e-9959-5ba5beecf39a",
  "path": [{ "alias": "excludeFromBreadcrumb", "blockKey": null }],
  "value": 1
}

Response: { "success": true }

Follow-up get_umbraco_content immediately after:

{ "alias": "excludeFromBreadcrumb", "editorAlias": "Umbraco.TrueFalse", "value": false }

Neither a JSON boolean nor a JSON integer persisted.

Control case — Umbraco.TextBox, same document, same call pattern

Request:

{
  "tool": "update_umbraco_content",
  "key": "6cce0498-da64-488e-9959-5ba5beecf39a",
  "name": null,
  "propertyValues": { "phoneNumber": "0207100000" }
}

Follow-up get_umbraco_content:

{ "alias": "phoneNumber", "editorAlias": "Umbraco.TextBox", "value": "0207100000" }

✅ Persisted correctly — confirms the document itself is writable and the tool-call plumbing works; the failure is specific to the Umbraco.TrueFalse editor/value type.

We've separately observed the same "reports success, value comes back reset" pattern when setting a content picker property. We don't yet have as detailed a request/response trace for this as the TrueFalse case above, but the symptom is identical: write reports success, the value doesn't stick. Flagging in case it points to a shared root cause (e.g. value-conversion handling for any property editor whose stored value isn't a plain JSON string/number) rather than something Umbraco.TrueFalse-specific.

Expected result / actual result

Property value(s) to be set as requested (or "success": false to be returned if relevant). As per examples above, we receive "success": true but the requested value(s) do not persist.

Dependencies

No response

[mattbrailsford]

The fix is merged into both release branches (v17 and v18) and will ship in the next published version of Umbraco.AI for each line — not sure yet whether that's another RC or the final release, but I'll follow up here once it's out with the exact version numbers.

For reference, the merged PRs: #410 (v18), #411 (v17).