We investigated the failing E2E test (redirects › internal target, navigation: thrower: loader, reloadDocument: true, preload: false) and determined it is unrelated to this PR's changes, which are scoped entirely to Link re-render bail-out logic in link.tsx. The test's full-page-reload detection is timing-sensitive in Playwright/Chromium and matches the task's measured flakiness rate of ~1.5%. We recommend re-running CI to confirm.
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 (redirects › internal target, navigation: thrower: loader, reloadDocument: true, preload: false) asserts that a redirect thrown from a loader with reloadDocument: true triggers a full browser page reload (expect(fullPageLoad).toBe(reloadDocument)).
The PR exclusively modifies packages/react-router/src/link.tsx — refactoring how Link subscribes to the location store to bail out of unnecessary re-renders. It has no changes to redirect handling, loader execution, or reloadDocument behavior.
The navigation itself succeeded (URL matched, the PostsIndexComponent was in the viewport), but the full-page-reload detector returned false instead of true. This kind of detection relies on browser navigation-type signals, which are timing-sensitive in a Playwright/Chromium environment and can intermittently misfire.
The task has a measured flakiness rate of ~1.5% (non-zero), consistent with rare, non-deterministic failures.
No similar failures were found in other branches, ruling out a persistent environment or configuration issue.
Given all of the above — unrelated domain, non-zero flakiness rate, timing-sensitive browser reload detection, and no cross-branch recurrence — this is classified as a flaky task rather than a code change regression.