We don't believe this is a code change: the failing test lives in an SSR stream-transform module that this PR never touches, and the failure is a hard timeout, not an assertion mismatch tied to the renamed Link tuple fields. Sibling "large string record" tests in the same file ran close to the same timeout boundary (3.3s–4.1s), which points to a load-sensitive, pre-existing timing issue rather than a regression from our changes.
Self-Healing CI
Classification: Environment state
No code changes are applicable.
The AI model provider was experiencing issues when this fix was generated.
The decision that this was not a code_change rests on several independent pieces of evidence:
File scope mismatch: The PR's diff is entirely confined to the Link internals refactor — LinkView/LinkStore/LinkBuildTracking/LinkValue/LinkRegistry converted from object shapes to tuples in packages/router-core/src/link-state.ts, a two-line tuple-index change in router.ts's buildLocation tracking logic, and matching updates across react-router/solid-router/vue-router link.tsx files and their tests. The failing test file, tests/transformStreamWithRouter.test.ts, exercises SSR stream-transform and hydration-script batching logic, which lives in a completely different part of router-core and is untouched by any file in this diff.
Nature of the failure: The single failing test, "record-end does not split one large Node string record," failed with "Error: Test timed out in 5000ms" — a hard timeout, not a value/assertion mismatch. A code_change classification requires the error to reference specific changed code (renamed properties, function names, imports) and for removing the change to logically fix the issue. Neither condition holds here, since the tuple refactor never executes in this code path.
Timing evidence: Sibling tests in the same suite that process "large" string records completed just under the timeout threshold (4115ms and 3292ms), while the failing test's work reached 5078ms before being killed. This pattern is consistent with a test that is already marginal against its fixed 5s timeout, tipping over due to machine load/CPU contention rather than a functional regression.
Flakiness data: mcp__utilities__task_flakiness_rates reported 0%, which per the tool's own definition indicates a deterministic (not intermittent) failure — ruling out flaky_task, but this by itself doesn't indicate code_change either, since determinism can equally arise from a consistently tight timeout under consistent load.
Similar-failure check: A lookup against branch 8562 returned no comparable data, so it could not directly confirm the failure is pre-existing, but combined with the file-scope disjointness and timing evidence, the absence of any causal link to the diff was sufficient to rule out code_change.
Taken together, the failure could not be attributed to any specific line or symbol changed by this PR, so it was classified as environment_state rather than code_change.