Repository navigation
fix(studio): an edit the history could not record says why in the log - #5489
Conversation
Edit accuracy: accurate 2061 (base branch 2061), smooth 1525 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (1)
|
jrusso1020
left a comment
jrusso1020
left a comment
There was a problem hiding this comment.
Reviewed at ecc89187. I found no blocker.
The change: claimHeld now logs [history] <status>: "<label>" was not recorded as your edit: <reason>. Before, the line started with the label. The only thing that changes is the log text. A refused claim still returns null, so the write still lands as an outside change, and a 404 is still silent.
Where the status comes from: I checked it against post().
- An unreachable server gives
status: 0with "Studio could not reach its server." (the.catch(() => null)branch), which matches the new0case. - Any non-2xx reply passes its own
response.statusthrough, so the 409 and 500 cases are right. - A 2xx reply whose body can't be read logs as
[history] 200: … The history's reply was unreadable.That's correct, but it's a fourth shape the PR body doesn't list.
Callers: this exact string appears nowhere else in the repo. The only matches are this line and its tests, so nothing parses the old label-first form.
Host side: the tag now leads the line, so a host that matches on a leading [tag] against a fixed list (which already includes history) keeps the category. The free text after the tag is not the tag itself, so the label and the server's reason are still not forwarded as categories.
Tests: the 500 case is updated, and the new it.each covers 409 and unreachable. The unreachable stub rejects only /history/claim and passes every other URL to the real fetch, which keeps the rest of the hook working. CI's Test (studio) ran usePersistentEditHistory.test.ts (26 tests), and the job passed with 7876 tests. I didn't run it locally.
I didn't do a live Studio run against a refusing history server.
— Rames
What changes
When Studio saves an edit but its history server refuses to record it as the person's undo step, the console line now starts with
[history]and carries the HTTP status (0 when the server could not be reached):[history] 409: "Move clip" was not recorded as your edit: <server reason>Before, the line started with the edit's label, so a host that only forwards known tags (HyperFrames Desktop's error reporting keeps a fixed tag list, which already has
history) reported it as a bare "Error". With the tag a host can forward the line, and with the status it can tell a refusal from an unreachable server once its own filter reads the status. Behaviour is unchanged: the edit still lands as an outside change, as before.No visible change
Log text only, in
packages/studio/src/hooks/usePersistentEditHistory.ts(claimHeld). The tag shape follows the existing[studio]line inuseShadowPreviewReload.ts.Checked
usePersistentEditHistory.test.ts: a new case for a 409 refusal and an unreachable server, and the existing 500 case updated; all three fail without the change and the file passes 26/26 three runs in a row.