mirror of
https://github.com/penpot/penpot.git
synced 2026-11-05 19:53:15 -05:00
Andrey Antukh
aadb6255e8
A repaired save could leave the client that saved with a different state than the server: the websocket repair message could arrive before the HTTP response, while the save was still queued, and the client undid and re-applied the pending commit around it (R;U instead of U;R). The repair changes now travel in the update-file response. The saver applies them once its commit is acknowledged, and the file channel hides the repair message from the saver with :origin-session-id. The commits queued behind the acknowledged one are undone, the repair is applied and they are replayed, so the local order (C1;R;C2) matches the server's. The search index receives the repair and the pending commits through the same helper as the normal commit path. The notifications are published after the transaction commits, so a save that rolls back does not notify. The snapshot that a repair leaves keeps the file as it was before any change or repair. The pin of a plugin version treats a false answer as a failure, in the plugin and in the workspace, and so do rename and remove. The workspace shows a toast when the pin fails. The schema of the update-file result describes the real response, and the test helper runs the deferred hooks like the HTTP layer. A retry of a save whose response was lost can compute a second repair; the limitation is documented. Closes #12416 AI-assisted-by: deepseek-v4.1-flash