What happened?
In collaborative editing, operators/links/positions sync between clients through the Yjs shared model — but two pieces of workflow content do not: workflowSettings, and (since #8275) formBinding. Each client hydrates a private copy on load (WorkflowActionService), and getWorkflowContent() re-emits that private copy into every autosave, which persists the whole content JSON.
So: client A edits a setting (or the Form View definition) → A's autosave persists it → client B, whose private copy is still the old value, makes any graph edit → B's autosave persists the whole content with B's stale copy → A's edit is silently reverted in the DB. A's screen still shows the new value until reload; the overwritten value is recoverable from version history, but nothing tells the users it happened.
workflowSettings has had this since collaborative editing landed (low exposure — settings changes are rare one-shot toggles). content.formBinding (#8275) widens the exposure: form authoring is a long-lived editing session, so the window where a collaborator's graph edit can clobber it is much larger. First surfaced for formBinding by a Copilot comment on #8304.
Possible directions (not prescribing): move these into the shared model (a Y.Map alongside operatorIDMap etc.); or merge against the latest persisted content before a whole-content save; or field-level persistence.
How to reproduce?
- Open the same workflow in two browsers (A and B), both with write access.
- In A: change a workflow setting (e.g. the data transfer batch size in the settings panel). A autosaves.
- In B (without reloading): drag any operator. B autosaves.
- Reload either browser: the setting is back to its old value — B's save carried B's stale private copy over A's edit.
The same mechanism applies to content.formBinding once its authoring UI lands.
Version/Branch
main
What happened?
In collaborative editing, operators/links/positions sync between clients through the Yjs shared model — but two pieces of workflow content do not:
workflowSettings, and (since #8275)formBinding. Each client hydrates a private copy on load (WorkflowActionService), andgetWorkflowContent()re-emits that private copy into every autosave, which persists the whole content JSON.So: client A edits a setting (or the Form View definition) → A's autosave persists it → client B, whose private copy is still the old value, makes any graph edit → B's autosave persists the whole content with B's stale copy → A's edit is silently reverted in the DB. A's screen still shows the new value until reload; the overwritten value is recoverable from version history, but nothing tells the users it happened.
workflowSettingshas had this since collaborative editing landed (low exposure — settings changes are rare one-shot toggles).content.formBinding(#8275) widens the exposure: form authoring is a long-lived editing session, so the window where a collaborator's graph edit can clobber it is much larger. First surfaced for formBinding by a Copilot comment on #8304.Possible directions (not prescribing): move these into the shared model (a
Y.MapalongsideoperatorIDMapetc.); or merge against the latest persisted content before a whole-content save; or field-level persistence.How to reproduce?
The same mechanism applies to
content.formBindingonce its authoring UI lands.Version/Branch
main