Summary
site_update_node_props can return {"ok": true} without persisting the patch. The response is indistinguishable from a successful write, so the only way to know is to read the document back and count.
Steps to reproduce
- Run a bulk sequence of
site_update_node_props calls against one document. The run here was 72 property patches.
- Collect the responses. All 72 returned
{"ok": true}.
- Re-read the document and compare against the intended state.
- One node did not carry its patched value (~1.4%).
- Re-issue that single patch on its own. It succeeds.
Expected behavior
ok means persisted, or the response carries something the caller can verify against — the resulting node state, a version, a hash.
Actual behavior
ok is returned for a write that was discarded. Nothing in the response distinguishes it, and no error is surfaced anywhere.
At this rate it is invisible on small edits and effectively guaranteed on large ones. Every write has to be followed by a read-back and a count, then a retry pass for the misses, which turns a write tool into a write-then-verify-then-retry tool.
Returning the persisted node state (or a version/hash) would let the caller verify in the same round trip. Surfacing the underlying failure instead of reporting ok would remove the need to verify at all.
Related, and possibly the same root cause: silent no-op on an unknown prop key. Patching a bare alt key on base.image behaves the same way — returns {"ok": true} and does nothing, because the module has no alt prop. Alt text only lands via htmlAttributes, and the renderer then appends its own empty alt="", producing a tag with two alt attributes. HTML5 tree construction keeps the first, so the injected value happens to win — the markup is invalid and the correct outcome is incidental. An unknown prop key should be rejected rather than accepted and dropped.
(The alt-text metadata gap itself is covered by #416. This is specifically about the write reporting success for input it discarded.)
Version or commit
Live hosted workspace, 30–31 Aug 2026. Workspace version not recorded; latest tag at the time of writing is v0.0.17.
Deployment mode
Hosted
Logs or screenshots
Bulk run: 72 patches issued, 72 ok responses, 71 values present on read-back.
Summary
site_update_node_propscan return{"ok": true}without persisting the patch. The response is indistinguishable from a successful write, so the only way to know is to read the document back and count.Steps to reproduce
site_update_node_propscalls against one document. The run here was 72 property patches.{"ok": true}.Expected behavior
okmeans persisted, or the response carries something the caller can verify against — the resulting node state, a version, a hash.Actual behavior
okis returned for a write that was discarded. Nothing in the response distinguishes it, and no error is surfaced anywhere.At this rate it is invisible on small edits and effectively guaranteed on large ones. Every write has to be followed by a read-back and a count, then a retry pass for the misses, which turns a write tool into a write-then-verify-then-retry tool.
Returning the persisted node state (or a version/hash) would let the caller verify in the same round trip. Surfacing the underlying failure instead of reporting
okwould remove the need to verify at all.Related, and possibly the same root cause: silent no-op on an unknown prop key. Patching a bare
altkey onbase.imagebehaves the same way — returns{"ok": true}and does nothing, because the module has noaltprop. Alt text only lands viahtmlAttributes, and the renderer then appends its own emptyalt="", producing a tag with twoaltattributes. HTML5 tree construction keeps the first, so the injected value happens to win — the markup is invalid and the correct outcome is incidental. An unknown prop key should be rejected rather than accepted and dropped.(The alt-text metadata gap itself is covered by #416. This is specifically about the write reporting success for input it discarded.)
Version or commit
Live hosted workspace, 30–31 Aug 2026. Workspace version not recorded; latest tag at the time of writing is v0.0.17.
Deployment mode
Hosted
Logs or screenshots
Bulk run: 72 patches issued, 72
okresponses, 71 values present on read-back.