fix(sentry): restore server error reporting

Merged
PR
12h ago
+969-172

Description

Consolidate the two instrumentation files into src/instrumentation.ts, alongside src/app. Initialize Sentry before the existing Node services and export the server-request error handler. Check the compiled hook exports in CI.

Register notification listeners before handling requests. Warm the Switch and 3DS catalogs in the background so a stalled download cannot block server readiness. Share pending catalog loads with early lookups. Refresh invalidates the pending load and protects data and search indexes from older completions. Bound provider requests and response bodies to 30 seconds and preserve their original errors.

Report handled tRPC 5xx failures in web and mobile adapters while preserving responses and development-only diagnostics for expected 4xx failures. Keep the same diagnostic Error through legacy logging and tRPC so Sentry deduplicates it, including unmapped Prisma failures. Serialize only known application error codes; provider metadata stays out of the public appError payload.

Remove unused Edge configuration and boilerplate. Label errors by environment and release, preserve injected release fallbacks, retain captured errors and sample 10% of traces. Default PII collection stays disabled; Replay sampling is unchanged.

Type of change

  • Bug fix

How Has This Been Tested?

  • Full unit suite: 2,153 passed, 4 skipped.
  • TypeScript, focused ESLint, Prettier and diff checks.
  • HTTP-adapter tests for 5xx capture, 4xx exclusion and development diagnostics.
  • Exported web/mobile GET handlers report handled 500s and exclude expected 401s.
  • Error-cause identity and public metadata isolation tests.
  • Instrumentation initialization and release-label tests.
  • Startup tests with stalled and failed catalog initialization.
  • Real catalog initializers recover from a provider outage on their scheduled refresh; concurrent loads share downloads and failed loads can retry.
  • Overlapping refresh/lookup completion orders, cache clearing and retry after stalled headers or response bodies.
  • GitHub CI at 56b01c0a: unit, lint/types, production build, compiled-hook and browser checks passed.
  • Staging release b9c66d2e: synthetic server-hook event received with the correct environment and release.

Screenshots (if applicable)

Not applicable.

Checklist

  • Code follows project conventions.
  • Performed a self-review.
  • Local checks pass.

Notes for reviewers

Google purchase-verification code is unchanged. Its malformed production key was corrected separately, using the existing credential. No schema or migration changes.

Both deployed images use Node.js, with no Edge functions. Staging Sentry is enabled; a synthetic server-hook event was received with the matching release. Production promotion remains separate. The 10% trace rate is an initial volume limit, not a measured optimum. Source-map upload remains separate work.

Catalog services deliberately keep their refresh timers running when the initial provider download fails. Their initialized flag describes the running service, not dataset availability. The provider-outage test covers this path with the real initializers and confirms scheduled recovery; the separate rejection test covers an initializer failure.