mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-10-30 09:16:55 +00:00
Vance IngallsandClaude Code
5a8ee663f7
* fix(studio): report a rejected read as a network reason, not an open failure `stage: "open"` is documented as `openComposition` threw — an unparseable composition, or OOM. Every event in that bucket on 0.8.56 and 0.8.57 carries a fetch-rejection message instead: "Failed to fetch" (28 users / 11 users), "Load failed", "NetworkError when attempting to fetch resource.". The cause is one missing catch. `readProjectFileOptional` awaits `fetch` with no try/catch, so a rejected request escapes the function and is caught by the effect's outer `.catch` — the handler written for `openComposition`. The read path has a five-member reason union precisely so this class of failure is diagnosable, and the one case that never produces a response was the case outside it. That made the largest SDK-session failure class in Studio (2.9% of session users on 0.8.56, 2.3% on 0.8.57) unaddressable: you cannot fix a network failure while it is reported as a composition that failed to parse. Now `readProjectFileOptional` catches its own rejection and returns `reason: "network"`, so it lands in `stage: read` with everything else, and `stage: open` means only what its comment says. Telemetry only. Nothing branches on the stage and no user-facing behaviour changes. Fifth split of this shape, after `ineligible_operation` (v0.8.49), `stage: read` (v0.8.51) and `block_detail` (#4214). Co-Authored-By: Claude Code <noreply@anthropic.com> * test(docs): point the catalog tab-row test at the page gutter #4238 moved the inset to `catalog-detail.test.ts` asserted the exact strings that #4238 deleted: `.hf-ve-tabs-row { margin: 20px 0 0 16px; }` and `.hf-ve-body { padding: 2rem 0 0 16px; }`. That PR removed both insets deliberately — its own comment says "the page gutter is the page's job, and a second 16px here put everything below the stage on a different left edge from the title, install block and stage above it" — and restored the gutter on `#content-area` in `docs/custom.css` instead. The test was left asserting the old mechanism, so main has been red on it since, unnoticed because the `Test` workflow does not run for a docs-only change. The invariant did not change: this content is still inset from the page edge. Only the mechanism did, so the test now asserts both halves of it — the two rules carry no inset of their own, and the gutter standing in for them is still present, at both its values. Asserting only the first would keep passing if the gutter were deleted outright, which is the regression the test exists to catch; both mutations were checked and both fail. Co-Authored-By: Claude Code <noreply@anthropic.com> --------- Co-authored-by: Claude Code <noreply@anthropic.com>