[DO NOT MERGE] probe: 42867 e2e with Sentry runtime disabled - #44581
[DO NOT MERGE] probe: 42867 e2e with Sentry runtime disabled#44581MajorLift wants to merge 69 commits into
Conversation
Agent-Logs-Url: https://github.com/MetaMask/metamask-extension/sessions/66deb05c-d6c0-4fae-953c-8842d8e47c25 Co-authored-by: MajorLift <34228073+MajorLift@users.noreply.github.com>
Agent-Logs-Url: https://github.com/MetaMask/metamask-extension/sessions/66deb05c-d6c0-4fae-953c-8842d8e47c25 Co-authored-by: MajorLift <34228073+MajorLift@users.noreply.github.com>
Agent-Logs-Url: https://github.com/MetaMask/metamask-extension/sessions/66deb05c-d6c0-4fae-953c-8842d8e47c25 Co-authored-by: MajorLift <34228073+MajorLift@users.noreply.github.com>
Agent-Logs-Url: https://github.com/MetaMask/metamask-extension/sessions/66deb05c-d6c0-4fae-953c-8842d8e47c25 Co-authored-by: MajorLift <34228073+MajorLift@users.noreply.github.com>
Agent-Logs-Url: https://github.com/MetaMask/metamask-extension/sessions/66deb05c-d6c0-4fae-953c-8842d8e47c25 Co-authored-by: MajorLift <34228073+MajorLift@users.noreply.github.com>
Agent-Logs-Url: https://github.com/MetaMask/metamask-extension/sessions/b03175d9-7847-4981-aaca-bd62f1537b2e Co-authored-by: MajorLift <34228073+MajorLift@users.noreply.github.com>
The `@sentry/browser` v8→v10 upgrade crashed the extension on boot under LavaMoat scuttling, failing every e2e job at `.controller-loaded`. v10's `browserTracingIntegration` registers an INP listener via `globalThis.addEventListener` synchronously inside `Sentry.init`, v10 web-vitals (`whenIdleOrHidden`) feature-detects `requestIdleCallback`, and v10 also reads `Request`/`WebAssembly`. Scuttling hid or threw on these. Webpack scuttles the shared realm with throwing getters, so add `WebAssembly`, `Request`, and `requestIdleCallback` to the `scuttleGlobalThis` exceptions in `LavamoatPlugin`. The browserify `sentry-install` bundle reaches Sentry through a proxy whose allowlist (`scuttlingConfigBase`) omitted `addEventListener`; add it and `removeEventListener`, bound to `window` like `setTimeout`.
The hook spread the raw Sentry `Span`; `@sentry/core` v10 exposes `undefined`
internal fields (e.g. `_endTime`) that fail the `snap_startTrace` response's
`Json` validation and reject the RPC — surfacing as an `UnexpectedAlertOpenError`
in the preinstalled-example snap e2e test. Return `{ traceId, spanId }` from
`spanContext()` instead.
Under the v10 SDK's startup timing the Home page mount reliably sets `pendingShieldCohort` before the test error is captured, so the masked Sentry UI-state snapshot is `string` rather than `null`.
…hrough v10 tracing emits hundreds of performance envelopes per test (~800 in a failing multichain run). Passing them through to real sentry.io starved e2e startup and flaked the non-EVM account render, and consumed the metamask-performance quota from CI. Return a canned 200 locally instead.
…pshots The field is populated by the Home page mount, so it is captured as `null` or a string depending on timing; under v10's startup it flips and breaks the state snapshot. Drop it from the comparison like other timing-dependent fields rather than pinning a racy value.
Bisection for the v10 non-EVM (Solana) account-render timeout: v8 renders the account ~instantly, v10 not within 10s, with identical envelope volume (~570) — so it is v10's heavier per-operation browser-tracing instrumentation (long-animation-frame / INP / fetch observers) at e2e's 100% sample rate, not the telemetry traffic. e2e does not consume these traces; skipping the integration there removes the overhead (and the CI quota draw).
The bisection it tested is refuted: skipping browserTracingIntegration in e2e did not fix the non-EVM account-render timeout, and it broke metrics/traces (no traces) and regressed metrics/errors. Restore the de-flaked state.
Second timing-dependent field in the same snapshot: the profile-sync SRP session is only present once account-sync establishes it, so its capture varies across runs. Drop it from the comparison like `pendingShieldCohort`.
The refuted e2e browser-tracing gating slipped back in because the prior revert moved the branch ref without updating the worktree. Restore setupSentry.js to its un-gated state; keep the srpSessionData de-flake.
Root cause of the snap/multichain e2e failures: the shared `waitForNonEvmAccountsLoaded` (hit by every login-based test) waits for the Solana/Bitcoin snap account icons with the default 10s timeout. The icons render in <1s locally, but on constrained 2-core CI runners the v10 Sentry SDK's heavier startup pushes the render just past 10s — so it's a runner timing margin, not a functional regression (the specs pass locally on v10). Allow 30s for these snap-backed icons.
Reconcile `yarn.lock` against the merged `package.json`, keeping the v10 `@sentry/*` resolutions alongside main's dependency bumps.
After a wallet unlock the controllers re-initialize, and the v10 Sentry SDK's heavier startup pushes `.controller-loaded` past the default 10s selenium wait on 2-core CI runners (`multichain-accounts/add-account.spec.ts` "added account should persist after wallet lock"). Bump the startup wait in `navigate` and `waitForControllersLoaded` to 30s without inflating the global `this.timeout`.
Resolve `errors.spec.ts`: drop `MetaMetricsController.latestNonAnonymousEventTimestamp` from `removedBackgroundFields` per main's #43556 (the field was removed from the controller), keeping the timing-dependent `pendingShieldCohort` / `srpSessionData` masks. Reconcile and dedupe `yarn.lock` against the merged `package.json` (material-ui→mui migration, `transaction-controller` 67→68).
The `.controller-loaded` and snap-backed non-EVM icon waits are polled ceilings, not fixed delays — they return as soon as their readiness signal appears. The earlier hard-coded 30s only mattered on a genuine hang, but it also slowed local failures from 10s to 30s for no benefit (local runners aren't the 2-core CI constraint). Replace the four literals with a single named `STARTUP_LOAD_TIMEOUT` (30s on CI, 10s locally): CI keeps the headroom for the heavier Sentry v10 startup, local fails fast again.
MajorLift
added
no-changelog
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
✨ Files requiring CODEOWNER review ✨🫰 @MetaMask/core-platform (1 files, +9 -4)
👨🔧 @MetaMask/extension-platform (2 files, +14 -4)
📜 @MetaMask/policy-reviewers (8 files, +216 -296)
Tip Follow the policy review process outlined in the LavaMoat Policy Review Process doc before expecting an approval from Policy Reviewers. 🧪 @MetaMask/qa (2 files, +57 -12)
👨🔧 @itsyoboieltr (1 files, +5 -0)
|
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Caution MetaMask internal reviewing guidelines:
|
Builds ready [4a5115a]
⚡ Performance Benchmarks (Total: 🟢 17 pass · 🟡 7 warn · 🔴 0 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Builds ready [09ab477]
⚡ Performance Benchmarks (Total: 🟢 13 pass · 🟡 10 warn · 🔴 1 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Resolves the browserify-removal conflicts by accepting main's deletion of `development/build/index.js` and `development/build/scripts.js`; the branch's browserify-side Sentry wiring is obsolete with that pipeline gone, and the webpack path carries its own equivalent.
09ab477 to
512c716
Compare
512c716 to
28b2a81
Compare
Builds ready [28b2a81]
⚡ Performance Benchmarks (Total: 🟢 13 pass · 🟡 11 warn · 🔴 0 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
…entation SDK module scope and init run, globals and hooks exist, but all event processing, instrumentation, and transport are off. Arm A (tracing stripped) still stalled; this arm separates non-tracing init from bare SDK presence. Do not merge.
28b2a81 to
f67fd74
Compare
|
Builds ready [f67fd74]
⚡ Performance Benchmarks (Total: 🟢 14 pass · 🟡 10 warn · 🔴 0 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Diagnostic probe for the deterministic
import-custom-token-with-custom-networkstall on #42867 (shard 18, 6+ consecutive failures; backgroundaddNetworknever completes; spec passes on main).Same head commit as #42867 (
4a5115a06fb); the only difference is the manifest-flag line below, which disables Sentry at e2e runtime. Shard 18 green here → the stall is caused by v10 Sentry runtime behavior in test builds; still red → the cause is elsewhere in the branch.flags = {"sentry": {"forceEnable": false}}
Will be closed after one CI cycle; results recorded on #42867.