[miguel-heygen]

What

A script request that the page cancels itself (Chromium's net::ERR_ABORTED, e.g. a frame that is removed or a load the page stops) no longer counts as a failed script load. Before, any requestfailed on a script was recorded as a load failure, which starts the sub-composition wait's 2 s fail-fast grace, so a render whose timeline registered a little later failed with "A sub-composition timeline script failed to load" on every attempt. Every other network error and every HTTP error status still counts, and the cancelled request's browser diagnostic is still written.

Why

A cancelled request was never refused by any server; treating it as a refusal fails renders that would have completed.

Related work

Refs #7088 (the failure's origin and code). This sits on top of it: the cause it records is kept for every failure that still counts.

How

The requestfailed handler moves into an exported recordFailedRequest(session, request), which records a script load failure (with its cause) unless the error is the page's own cancel, then writes the diagnostic as before.

Test plan

• frameCapture-subTimelinePoll.test.ts › "a script request the page cancelled": a cancelled script records no failure and a timeline that registers after the grace ends the wait ready; a script the network refused (net::ERR_CONNECTION_RESET) is still recorded.

• fails without the fix: packages/engine/src/services/frameCapture-subTimelinePoll.test.ts › "a script request the page cancelled" › "is not a load failure: a timeline that registers after the grace still ends the wait ready" (with the cancel check removed: 1 failed, 22 passed).

• frameCapture-subTimelinePoll, frameCapture and frameCapture-subTimelineWarning tests: 94 passed, 3 runs in a row. oxlint and oxfmt clean on the changed files.

• A repro outside the test (a script cancelled by the page while its timeline registers after the grace) failed every attempt before this change.

• Unit tests added/updated

• Manual testing performed

• Documentation updated (if applicable)

• Comments follow CONTRIBUTING.md "Comments": they say why, not what, and a bug fix says what the code must do and how to reproduce the bug

Size

68 changed lines: a lone root fix with its test.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 90 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

[heygengenesis]

Requesting changes at d937f66a. The only blocker is the PR description.

Blocker: the body has no fails without the fix: line, so it doesn't name a test that fails without this change. That line is required for fix PRs. Please add one, for example:

fails without the fix: packages/engine/src/services/frameCapture-subTimelinePoll.test.ts › "a script request the page cancelled" › "is not a load failure: …"

Before you add it, confirm that the test actually fails when the ERR_ABORTED guard is reverted. With the guard gone, the scriptLoadFailures toEqual [] assertion fails, and so does the poll that should end "ready" after the grace period.

Code (no blocker):

• Moving the logic into recordFailedRequest keeps the same behavior. The only change is skipping net::ERR_ABORTED for scripts, and the browser diagnostic is still written for those.
• The engine doesn't intercept requests itself. The CLI interception path (captureCompositionFrame.ts:913) aborts with "failed", which shows up as ERR_FAILED, so a script the network refused is still counted as a failure. The second test covers this case.
• HTTP error statuses never fire requestfailed, so this change can't affect how they're counted.

[heygengenesis]

Approving at e8d98bc5. The one blocker from my last review is fixed, and I re-checked the change against #7088, which has now merged.

• fails without the fix: line: present, and I confirmed it locally. With the ERR_ABORTED guard removed, the named test fails (× is not a load failure…, 1 failed / 22 passed). With the guard in place, all 23 tests pass.
• On top of #7088: recordFailedRequest passes classifyScriptLoadCause(...) through, so failures that still count keep their recorded cause. A cancelled script records no URL and no cause, and its browser diagnostic is still written.
• Other tests: the frameCapture-subTimelinePoll, frameCapture and frameCapture-subTimelineWarning tests all pass (94 total), and tsc --noEmit on the engine package is clean.
• Other failures still count: the engine doesn't intercept requests, and the CLI's own blocking aborts with "failed", so those scripts are still recorded as failures. HTTP error statuses never fire requestfailed.

No blockers.