Repository navigation
Conversation
eb36426 to
3bd532c
Compare
karanb192
left a comment
There was a problem hiding this comment.
1. Blocking: check the current project file before saving an open project's edits.
At hooks/project.tsx:1476-1488, an open project uses the cached projectAtom and skips reading its file. The revision guard tracks only this loaded session. If another session updates a block's logic, the next apply in the first session writes its cached project over that update through saveProject at lines 327-332.
Reconcile external changes or refuse a stale edit before saving. Apply the same protection to direct board edits, which also save cached state.
Verified good: Source 523e643cbb4287a0c9bb97eb18823e7b323065d9 passes all 175 original engine tests and plugin validation. The added regression writes a project, changes its file externally, then adds an unrelated block through the tool: expected the newer logic, received the original. File I/O is mocked. The existing two-surface prompt-band preservation test passes.
|
Thanks for the careful review and for catching this. It was a real data-loss bug. It's fixed in v0.4.3 (bruw/workflow-conductor#8). Every save now checks the file against what the session last read or wrote, and if another session changed it write is skipped. This covers both tool edits and direct board edits:
Added a regression test |
karanb192
left a comment
There was a problem hiding this comment.
1. Blocking: protect the complete read-to-write project update from overlapping saves.
At hooks/project.tsx:366-383, saveProject still writes unconditionally after its preflight read. The independent regression saves a newer project between that read and write; the saved logic changes from concurrent external save back to original. Protect the entire update or fail on conflict without replacing the newer file. Another comparison before an unconditional write leaves the same gap.
Verified good: The older external-edit case and strict validation pass. The new invalid-file protection does not cover this overlap. One author-suite timeout remains in isolation, separate from this reproducible data-loss failure. Filesystem calls were mocked.
Reviewed upstream source: fa1ea338c05d6078d5e0514394240f0653f93f5e.
Yeah that's valid, I documented the gap in the PR. RCA: Mod Engine does not provide atomic read-write operations. So before we write we first read the file and compare it has not moved. That leaves a short gap between read and before the write where the file could be written to by another process without plugin knowing. Since the engine does not provide atomic read-write, there will always be this gap. The only other solution I could think of was adding a lock, but that's overly complex and it still only guards the multiple plugin sessions on one file - not a likely scenario and not a universal fix. Will keep it as is for now with this case documented, until a solution is found or it proves to be a real issue. |
Adds
bruw/workflow-conductortodata/seeds.txt(alphabetical, ignoring case).Conductor is a terminal UI for planning, running and understanding complex agent workflows inside Claude Code: a designer pane and a one-line band above the prompt, the
/conductorcommand, and two tools of its own that Claude calls to read and edit a project and before writing a Workflow script. Its hooks read agent spawns, model turns and turn ends to draw a Workflow run on the plan. It makes no network requests and runs no programs; it writes only its project files under.claude/. The band hook passes downstream content through (next(e)).MIT. Requires Claude Code 2.1.296+.
claude plugin validatepasses on v0.4.2.Disclosure: I'm the author.