Reduce Sentry tracing span volume

[rlinoz]

Background

A Sentry health check found several high-volume tracing spans in the App over the previous 30 days (roughly 820M spans). We should reduce spans that do not offer meaningful debugging value while preserving useful application telemetry.

Proposed solution

Review and selectively filter these sources:

1. Browser resource spans — resource.link (CSS/fonts, ~130M) and resource.script (JavaScript, ~92M). Consider filtering these browser SDK auto-instrumented spans if the Assets Dashboard is sufficient for debugging them.
2. Onyx derived computations — OnyxDerivedCompute accounts for ~24% of span volume (6–11M/day). Evaluate retaining only computations above a duration threshold, independently sampling them, or removing the instrumentation if it is not useful.
3. Google Analytics/Ads requests — exclude third-party HTTP spans for ccm/collect, rmkt/collect, pagead/form-data, and ccm/form-data (~80M+ spans) if they have no debugging value. Prefer scoping trace propagation to Expensify domains where appropriate.
4. Ping heartbeat — assess whether GET https://www.expensify.com/api/Ping (~11M spans) has troubleshooting value; exclude it if it is only a heartbeat.

Start with third-party and browser-resource spans, then review the Onyx instrumentation.

Source

https://expensify.slack.com/archives/C0A3FPPTGJY/p1789660108556719

Issue Owner

Current Issue Owner: @rlinoz

[rlinoz]

@MelvinBot look at how we implement sentry in the app and tell me how can we eliminate the spans from 1,2,4?

[MelvinBot]

All three are fixable in App, and two of them are one-line config changes. Ordered by effort/volume:

1. Browser resource spans (~222M) — pass ignoreResourceSpans to our browser tracing integration in src/libs/telemetry/integrations/index.web.ts:20:

const tracingIntegration = SentryReact.browserTracingIntegration({
    shouldCreateSpanForRequest,
    ignoreResourceSpans: ['resource.link', 'resource.script'],
});

The SDK never creates the span — _addResourceSpans early-returns when the op is in that list. Trade-off to decide first: these spans are what feeds Sentry's Insights → Assets module for CSS/JS, so that module goes empty for those types. LCP/FCP/CLS/INP are measurements on the pageload transaction, not resource spans, so web vitals are unaffected.

4. Ping (~11M) — add /api/Ping to filteredPhrases in shouldCreateSpanForRequest, src/libs/telemetry/integrations/common.ts:5 — exactly the /api/Log precedent already there. One line, applies to web and native, and no span is created. The volume comes from the NetInfo reachability poller, whose URL is built as …/api/Ping?accountID=… in src/libs/NetworkState.ts:328, so the substring matches.

2. OnyxDerivedCompute (~24%) — no SDK switch for this one; it's our own instrumentation in src/libs/actions/OnyxDerived/index.ts:121-128, and it already has onlyIfParent: true, so the remaining volume is real recomputes during startup/send-message. Two ways to threshold it:

• At the source (best). Time the compute with performance.now() and only start the span when it exceeds a threshold (one frame, ~16ms, is a reasonable start), creating it retroactively with an explicit startTime. startSpan already accepts startTime (activeSpans.ts:31); endSpan would need to take an end timestamp. Nothing is created or serialized for the fast majority.
• Cheaper to ship. A new beforeSendTransaction middleware that drops child spans with op === 'OnyxDerivedCompute' below the threshold — same shape as httpClientCancelledFilter.ts:8, registered in middlewares/index.ts:14. Safe to drop: nothing passes these spans as a parentSpan, so there are no children to orphan.

If you'd rather keep specific slow keys instead of a duration cut, the span already carries a derivedKey attribute you can filter on.

Supporting detail

How our Sentry setup is wired. src/setup/telemetry/setupSentry.ts:49 calls Sentry.init from @sentry/react-native with tracesSampleRate: 1.0, an integrations list from @libs/telemetry/integrations (web/native split), and beforeSendTransaction: processBeforeSendTransactions, which runs the middleware chain in @libs/telemetry/middlewares. So there are exactly three places to cut spans: integration options (never created), our own startSpan call sites, and the beforeSendTransaction middlewares (created but not sent).

A fourth, declarative option. @sentry/react-native@8.25.0 bundles @sentry/core@10.73.0, which supports ignoreSpans in Sentry.init — name/op/attribute matching that drops spans in processBeforeSend and reparents their children. It would cover items 1 and 4 in one config block, and it's the right tool if you want a single list. Two caveats: it runs before our middlewares, and if the matched span is the root span the whole transaction event is dropped (relevant for Ping, whose fetch span can be its own root when no pageload/navigation span is active — which is probably desirable here anyway). The per-integration options above still beat it for items 1 and 4 because they avoid creating the span at all.

Don't use beforeSendSpan for this. In @sentry/core@10.73.0, returning null from beforeSendSpan for a child span does not drop it — the span is pushed anyway and a drop warning is logged. Only ignoreSpans or filtering event.spans in beforeSendTransaction actually removes spans.

Tests to update: tests/unit/onyxDerivedComputeSpanTest.ts asserts on span creation for item 2; tests/unit/setupSentryTest.ts and setupSentryIntegrationOrderTest.ts cover the init config.

---

Next Steps: Reply with @MelvinBot implement this to open a draft PR for items 1 and 4, or @MelvinBot <your feedback> to refine.

[rlinoz]

@MelvinBot Sorry I meant 1,3,4, create a draft pr for those

[MelvinBot]

Draft PR: Filter high-volume Sentry spans: browser resources, Google Ads/Analytics, and Ping — covers items 1, 3 and 4. It's assigned to you and PullerBear is requested; mark it "Ready for review" when the test/QA steps are filled in. Item 2 (OnyxDerivedCompute) is untouched, since that one needs a duration threshold on our own instrumentation rather than a filter.

What each item became, in three small changes:

1. Resource spans (~222M) — browserTracingIntegration now passes ignoreResourceSpans: ['resource.link', 'resource.script'] in src/libs/telemetry/integrations/index.web.ts:19-29. The SDK never creates the spans. One trade-off to accept before merging: those spans are what feeds Sentry's Insights → Assets module for CSS/JS, so that module loses data for those two types. Web vitals are unaffected.
2. Google Ads/Analytics (~80M+) — ccm/collect, rmkt/collect, pagead/form-data and ccm/form-data are added to the existing shouldCreateSpanForRequest filter in src/libs/telemetry/integrations/common.ts:4-22. I left trace propagation alone — scoping tracePropagationTargets also changes the headers we send to our own API, so it belongs in its own change if you want it.
3. Ping (~11M) — /api/Ping joins the same filter, same precedent as the /api/Log entry already there. This covers the NetInfo reachability poller, which is where the volume comes from.

All three cut the spans at creation time rather than dropping them in beforeSendTransaction, so there's no client-side work and no payload for the filtered requests.

Tests run

Two unit tests were added: shouldCreateSpanForRequestTest.ts covers the new URL filters, and webTracingIntegrationTest.ts asserts ignoreResourceSpans reaches the browser SDK.

• npm run lint-changed and npx eslint on the changed files — passed
• npm test on the four telemetry suites (new tests plus setupSentryTest, setupSentryIntegrationOrderTest) — 16 tests, all passed
• npm run spell-changed — passed (pagead and rmkt added to cspell.json)
• npm run typecheck — tsconfig.app.json passed. tsconfig.jest.json has 2 pre-existing errors in tests/unit/ModifiedExpenseMessageTest.ts about a missing movedFromReportName property; that file is untouched here and the failure is unrelated.
• A browser smoke test could not be completed: the automated web session handed to this run had already failed to sign in before these changes existed and was showing a blank page by the time the check ran, so nothing about this branch was observable in it. webTracingIntegrationTest.ts does at least import and evaluate index.web.ts, which is the module that would have to throw for app bootstrap to break.