[P1] E2E performance monitoring has been blind since 17 July — CI telemetry stopped reaching Sentry

[MajorLift]

Parent Epic: #43410 - Sentry Quota Breach — Extension Telemetry (May 2026 – ongoing)
Surface: e2e CI telemetry path — app/scripts/lib/setupSentry.js, manifest flag injection, e2e workflows
Size: M | Priority: P1

---

Problem

E2E performance monitoring has produced no data since 17 July 2026. The metamask-performance Sentry project went from 6.53M transactions/day to 0.26M in a single day and has stayed there.

The tell is that every ci.job tag value disappeared at once. Before the stop, four e2e jobs were each emitting 60–71M (extrapolated) over a 9-day window; afterwards, the only remaining value is (unset). CI still runs — it no longer identifies itself to Sentry.

ci.job	08–16 Jul	08–17 Aug
test-e2e-chrome-browserify	71.1M	—
test-e2e-chrome-webpack	70.0M	—
test-e2e-firefox-webpack	59.8M	—
test-e2e-firefox-browserify	59.4M	—
(unset)	57.9M	2.5M

ci.branch:main fell from 39.2M to 40.8K — a 960× drop.

Impact

Seven dashboards consume this project, carrying 204 widgets between them. Two were opened on 11 and 17 August, so this is a live monitoring gap rather than a stale one. Among them is E2E Performance CUFs (Power User where applicable), which filters every widget on ci.branch:main — a tag only CI sets. The others are E2E Performance CUFs !SPIKES!, Extension: e2e Performance Dashboard, Extension Performance — Benchmark Logs & E2E, Extension: Production Performance Metrics, Extension CI: PR Performance Benchmark Dashboard, and Extension: Build System Comparison, the last of which is itself obsolete now Browserify is gone.

Critical-user-flow performance regressions in onboarding, SRP import, send, swap and asset details can currently ship without the dashboards showing anything. Absent data reads as healthy rather than as unmeasured.

Investigation so far

Three candidate causes are excluded by evidence:

• #44451 (chore: reduce Sentry trace sampling) changes only the production rate, 0.75% → 0.5%. CI uses a separate ladder in getTracesSampleRate — 1.5% on main, 0.1% elsewhere — so it is arithmetically incapable of a 960× drop.
• The SENTRY_DSN_PERFORMANCE repository variable is still set, updated_at 2025-11-21, months before the stop. It was not disabled as a cost control.
• E2E still runs on main — eight runs since 1 August.

The leading candidate is #44433 (chore: remove browserify), merged at 00:05 on the stop day. It restructured e2e-chrome.yml, e2e-firefox.yml and main.yml, and deleted development/build/manifest.js, which injected manifest flags for the Browserify build. Two of the four lost job names are jobs that PR removed outright.

What that does not yet explain is why the surviving webpack jobs also went silent, since the webpack ManifestPlugin still merges flags. This is a well-supported candidate, not a proven cause.

Solution

1. Establish the cause. Build e2e either side of #44433 — 593690c0f7b^ against 593690c0f7b — and check whether _flags.ci reaches the runtime. getSentryTarget() returns the performance DSN only when manifestFlags.ci?.enabled is truthy (setupSentry.js:243), so if the flag is absent the DSN is never selected.
2. Restore emission, with the ci.job / ci.branch / ci.enabled tags intact, since every dashboard filters on them.
3. Restore at a deliberate sample rate rather than the previous one. See below — this is the part that should not be a straight revert.

Restore deliberately, not as it was

At 1.5% on main this project ran at 90.7M transactions/month — roughly three times the production extension project's entire quota allocation. Two findings bear on how it comes back:

• 78.6% of that volume was queried by no dashboard. Of 100 transaction names in the project, ten are named by a widget and account for 21.4%; the rest was the wallet's own production instrumentation firing incidentally during tests, led by AggregatedBalanceSelector at 159.7M.
• Every one of the 204 widgets computes a percentile, which needs sufficient samples rather than every event. Reducing the CI sampling rate preserves all of them at lower fidelity; a name allowlist would instead decide on the dashboards' behalf which names may ever be queried again.

For comparison, mobile obtains an equivalent capability on its own CI project for 13.9M/month.

Inbound filters are per-project. The AggregatedBalanceSelector filter was applied to the production project only, while that family was the largest single transaction here — so restoring without mirroring the filters brings back unmitigated volume.

Detection gap

This ran for a month with no signal. Seven dashboards were silently empty and two were opened during that window without the emptiness being connected to a cause. Alerting on this project is covered by #43411 (Add Sentry quota monitors/alerts for rate-limited and dropped events), which should include a floor alert — volume dropping to zero — not only a ceiling alert.

---

Acceptance Criteria

• Cause established by build comparison either side of #44433, with the result recorded here
• _flags.ci confirmed reaching the runtime in e2e builds on main
• ci.job, ci.branch and ci.enabled tags present on transactions in metamask-performance
• All 204 widgets across the seven consuming dashboards returning data
• A sampling rate chosen and recorded, with its resulting monthly volume measured rather than assumed
• Production inbound filters mirrored onto metamask-performance before volume is restored
• Floor alert added so a future silent stop is detected, tracked under [P1] Add Sentry quota monitors/alerts for rate-limited and discarded telemetry #43411

---

Labels

area-CI, area-testSuite

---

Dependencies

Related: #43411 (quota monitors/alerts — needs a floor alert, not only a ceiling alert)
Caused by, unconfirmed: #44433 (chore: remove browserify)
Blocks: Sentry renewal volume sizing — restoring as-was adds 90.7M transactions/month to the org total