[Flaky CI]: E2E react-router-7-framework-spa Test - [chromium] › tests/performance/pageload.client.test.ts:6:3 › client - pageload performance › should send pageload transaction

[github-actions]

Flakiness Type

Other / Unknown

Name of Job

E2E react-router-7-framework-spa Test

Name of Test

[chromium] › tests/performance/pageload.client.test.ts:6:3 › client - pageload performance › should send pageload transaction

Link to Test Run

https://github.com/getsentry/sentry-javascript/actions/runs/25647350049/job/75279506988

---

This issue was automatically created.

[linear-code]

JS-2426

[mydea]

Investigated this via /fix-issue (Claude Code). Aborting without a PR — fix is non-trivial and likely SDK-side.

Root cause

From the failing run:

Error: expect(received).toMatchObject(expected)

- Expected  - 2
+ Received  + 2

    "data": Object {
      "sentry.op": "pageload",
-     "sentry.origin": "auto.pageload.react_router",
+     "sentry.origin": "auto.navigation.react_router",
      "sentry.source": "route",
    },
    "op": "pageload",
-   "origin": "auto.pageload.react_router",
+   "origin": "auto.navigation.react_router",

The test waits for a transaction matching transaction === '/performance' && contexts.trace.op === 'pageload'. That filter resolved with a transaction whose op is 'pageload' but whose origin (both contexts.trace.origin and contexts.trace.data['sentry.origin']) is 'auto.navigation.react_router'. So the SDK is producing a transaction with an internally inconsistent label — semantically a pageload (correct op) but tagged with a navigation origin.

The test's expectation that pageload op → pageload origin is reasonable and matches the SDK's stated contract elsewhere. The flaky failure is therefore an SDK-side race: under some timing condition, the react-router pageload integration produces the right op but leaves the navigation origin in place (or the navigation integration overwrites origin without resetting op).

Why aborting

This needs a fix in the @sentry/react-router integration's pageload / navigation handler, not the test. Picking the right place to fix without (a) understanding the integration's transaction-lifecycle internals or (b) risking regressions in the navigation case is beyond what I can confidently land as a one-off small fix. Loosening the test to accept either origin would mask the real SDK bug.

Flagging for someone on the React Router integration to investigate the pageload/navigation origin race.