We believe this failure is unrelated to the changes in this PR. The failing "stream" test times out waiting for Suspense/streamed loader data to render, a code path this refactor never touches, while the flakiness rate for this task is non-zero and no similar failure appears on other branches, so we're classifying it as a flaky test rather than a regression.
Self-Healing CI
Classification: Flaky task
An empty commit was automatically applied to the branch to trigger a new CI pipeline execution to resolve the flaky task.
The failing test is tanstack-solid-start-e2e-serialization-adapters:test:e2e, specifically the "SSR serialization adapters › stream" case, which times out after 30s waiting for the stream-car-expected test id to appear.
Tracing the test: e2e/solid-start/serialization-adapters/src/routes/ssr/stream.tsx defines a loader that resolves a promise after a 1 second setTimeout, then renders the result inside a Suspense/Await boundary. None of the files involved in this route (the route file, RenderData, data.tsx) appear anywhere in the PR diff.
The PR itself only touches how a source ParsedLocation is threaded through navigate, buildLocation, and resolveRedirect (removing the _fromLocation option field and passing it instead as a separate, private positional argument). These changes affect navigation and redirect resolution — not the loader/Suspense/streaming data pipeline that the "stream" test exercises. The sibling "nested" test, which relies on the same loader/router/Suspense mechanics, passed in the same run, which further supports that the streaming/data-serialization path itself is unaffected by the refactor.
Additional evidence:
- The
similar-task-failure-detectorsubagent found no matching failure on other branches, ruling out a pre-existing/base-branch issue. mcp__utilities__task_flakiness_ratesreported a non-zero flakiness rate (~6.5%) for this task.- The task's project isn't directly modified by the PR (no e2e app files appear in the diff), and the failure mode (a single test timing out waiting on content that should resolve well within the 30s window) is consistent with test-infrastructure timing flakiness rather than a logical break introduced by the diff.
Based on this, the failure was classified as flaky_task rather than code_change.