mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-11-14 21:29:34 +00:00
Vance Ingalls
4bcc7e1882
Deleting a clip refused its own save. The flow reads the file, POSTs `remove-element` — which rewrites the file server-side — then saves the duration shrink on top. That second write carried the content read at the start as its optimistic-concurrency expectation, but the server had already moved the file on, so it came back 409 "file conflict". The save queue pauses on a conflict rather than retry stale work, so the error surfaced and nothing persisted afterwards; the clip stayed on the timeline until a reload, since the store update runs after the save and the throw skipped it. The undo baseline and "what is on disk" were one value in saveProjectFilesWithHistory, which is right until a server-side mutation has already written part of the edit. They are now separable: `diskContent` says what to expect on disk, `readFile` still says what undo restores. Both delete paths pass what remove-element left behind. Measured in the studio, before and after: PUT /files/index.html 409 -> 200, no error toast, the clip leaves the timeline immediately, and undo still brings it back. Pre-existing — reproduced identically on the pre-session studio source.