config-editor edit() read-back validation permanently fails for entries with volatile fields (0.1.7-rc.2)

[369829277]

Draft issue 2: config-editor edit() read-back validation permanently fails for entries that declare volatile fields

Version: dsh-v0.1.7-rc.2 (commit 477b4f4)

Summary. edit() validates a write by reading the entry back through plugin composition
("take the first row with the same id / compose via plugins") and comparing it to the intended
next config. For entries that declare volatile fields (e.g. ui-settings-general's
welcomeNoticeVersion), composition strips or rewraps the volatile fields, so the composed value
can never equal a next that contains them. Every such edit is rejected as
"overridden by home patch" — silently, because the protocol returns ok:false by design without
raising. Non-volatile fields in the same namespace (e.g. font size) fail along with them.

Related observation. SettingsForms.write is volatile-only by design (entries without
volatile fields throw "has no volatile fields"), which confirms volatile handling is special
cased — but the edit() read-back comparison was never adjusted for it.

Reproduction elements.

1. Any entry whose spec declares volatile fields; ui-settings-general with
   welcomeNoticeVersion is the shipped example (dsh-client-ui-settings-models client bundle,
   settings-general section).
2. Call edit() on that entry to set the volatile field (e.g. acknowledging the welcome
   notice sets welcomeNoticeVersion).
3. The write reaches the document, but the read-back comparison composes the row (volatile
   fields stripped/wrapped) against next (volatile fields present); equality never holds;
   the write is reported as overridden and effectively refused/rolled back at the settings
   layer. No error is surfaced.

Suggested direction (what we did locally). Make the read-back validation
document-faithful: after writing, yaml.load(document), merge rows with the same id from the
document itself, and compare that merged config against next. This compares what was actually
persisted instead of a composed projection, and is insensitive to volatile wrapping. Patch:
patches/dsh-config-editor@0.1.7-rc.2.patch (20 lines). After the patch: welcome-notice
acknowledgement both disappears and persists (the welcomeNoticeVersion row lands in the
profile patch), and font-size changes (14→15, ui-theme/fontSize) apply and persist; full chain
verified with zero console errors.

[davidgalvao]

Confirmed this issue on dsh 0.2.0-rc.2 using the Docker image runzhliu/deepseek-harness:0.2.0-rc.2-r1.

The symptom was exactly:

"The acknowledgement could not be saved. Please try again."

Environment:

• Docker
• http://localhost:3080
• @deepseek-ai/dsh-config-editor@0.2.0-rc.2
• ui-onboarding.welcomeNoticeVersion

I confirmed that the problem was not filesystem permissions or a stale .lock file. The config editor was rejecting the write during its read-back validation.

The problematic validation was effectively comparing:

composeEntries([patches]).find(...).config

against next.

For volatile fields such as welcomeNoticeVersion, the composed configuration does not faithfully represent the value that was actually written, so the comparison fails even though the document contains the requested value.

I patched config-editor to validate against the YAML document itself instead:

1. Parse the current document.
2. Select rows with the same entry ID.
3. Merge their persisted config objects.
4. Compare that persisted configuration with next.
5. Keep the existing reconcileProfilePatches() flow unchanged.

After rebuilding the Docker image with this patch and restarting the container:

• The welcome acknowledgement was accepted.
• The welcome modal disappeared.
• ~/.dsh/settings.yaml contained:

ui-onboarding:
  welcomeNoticeVersion: "2026-08-13.1"

So the document-faithful read-back validation appears to resolve the issue on 0.2.0-rc.2 as well.

Thanks for documenting the root cause here. This also provides a useful regression case for volatile settings persistence.
dsh-config-editor-volatile-settings-fix.patch