fix(reo): stop a blocked analytics script from reporting as a Studio error

[dawsontoth]

Studio loads Reo.dev analytics through the bundled reodotdev package. When an ad blocker blocks its CDN, loadReoScript rejects from the injected script's own onerror — and the chain in useReo had no rejection handler, so it became an unhandled rejection. Because the reject happens inside our bundle, the rejection's only located frame is index-*.js, which means shouldKeepEvent's reo.dev stack filter cannot attribute it away: it reached Datadog Error Tracking as an unhandled Studio error.

Found in the daily RUM review: 14 events across 5 sessions (4.3% of all sessions) in the 24h to 2026-08-27, against 0–1/day for the six days before, on the currently-served build (index-DFE8mV3G.js). Together with a second third-party family this accounted for a third of the day's error-sessions while total error volume fell — errors got broader, not louder.

This catches and drops the rejection (Reo is optional; nothing degrades without it), and starts the chain from a resolved promise so a synchronous throw from the vendor lands in the same handler — useReo() is the first hook in App.tsx with no error boundary above it, so an escaping throw would blank Studio rather than degrade analytics.

For the human reviewer

1. Which channel logs the swallowed failure. Chosen: silent. Settled during review: gemini flagged the empty catch and suggested console.error. That specific channel is the one this PR cannot use — the RUM SDK instruments console.error and reports it as a RUM error (error.source: "console", the same route shouldKeepEvent.ts:93-97 documents for React Query's handled AxiosErrors), so it would send the failure straight back into the Error Tracking issue this catch exists to remove. Now console.debug, which RUM does not collect (datadogRum only, no datadogLogs), so a genuine Reo breakage is visible in devtools at zero RUM cost. Nothing left open here unless you disagree that debug is discoverable enough — the alternative is a tagged datadogRum.addAction, deliberately not taken because it re-couples analytics failure to the error pipeline.
2. Fix at the integration vs. in the RUM filter. Chosen: the Reo call site. A reviewer who wants all third-party noise policy to live in shouldKeepEvent.ts could rule the other way. I ruled for the call site because the filter provably cannot do this job — it attributes on stack frames, and this stack's only frame is ours — so the filter alternative would have to match the message text, which that file's design deliberately avoids. The call site also covers the blank-screen case a filter cannot. The two fixes overlap and should not both land.
3. Promise.resolve().then(...) vs. try { … } catch {}. Chosen: the resolved-promise funnel, so sync and async failure share one handler instead of two. Purely a legibility call; fully reversible.
4. Mocked loader vs. a real failing <script>. Chosen: mocked reodotdev plus a stack fixture in shouldKeepEvent.test.ts pinning the premise. The real onerror seam is inside the vendor package and no unit test reaches it; if reodotdev ever rejects from somewhere the wrapper does not cover, the suite stays green. Reversible by adding a jsdom test later.

Verification

End-to-end route: not observable end-to-end from the repo — reproducing it needs a real ad blocker blocking static.reo.dev in a browser, and the resulting assertion is the absence of a Datadog event. Covered by unit tests at the seam instead, plus the production evidence above.

• npx vitest run — 327 files, 2709 passed, 11 skipped, exit 0.
• npx tsc -b exit 0; npx oxlint --format stylish . exit 0; npx dprint check exit 0.
• Mutation-checked, both guards (a test written for a containment bug is exactly the kind that silently tests nothing): deleting .catch(() => {}) fails 3 of 6 cases; removing the Promise.resolve() funnel fails the sync-throw case. Restored, 6/6 green. The sync-throw case initially passed under the .catch mutation — round 2 of the review caught that, and it now routes through collectUnhandledRejections so it fails for both.
• Symmetry check: src/integrations/google/gtm.ts and src/integrations/stripe/* were audited for the same unguarded-loader shape; Reo was the only remote-script loader with an uncaught chain.

Complexity: easy

_{Review-Coverage: authored=claude; ran=codex; blocked=gemini(quota); declined=cursor-grok,cursor-composer,domain; rounds=4 @ 76614fb}

_{Human-Review-Need: 3 @ 76614fb}

[gemini-code-assist]

Code Review

This pull request refactors the useReo hook to safely load and initialize the Reo script within a promise chain, preventing unhandled promise rejections and synchronous throws from crashing the application. It also adds comprehensive unit tests for useReo and updates the Datadog integration tests. The review feedback suggests logging the caught error in the .catch block of useReo instead of silently swallowing it, ensuring better visibility for debugging.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	59.56%	8004 / 13437
🔵	Statements	60.02%	8581 / 14295
🔵	Functions	52.38%	2023 / 3862
🔵	Branches	53.44%	5740 / 10741

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/integrations/reo/reo.ts	100%	100%	100%	100%

Generated in workflow #1822 for commit 2f0da6d by the Vitest Coverage Report Action

[kriszyp]

_{🤖 Reviewed with Codex}