feat(webapp): link Sentry events to OTel traces via trace_id

[d-cs]

Summary

Stamps the active OpenTelemetry trace_id and span_id onto every Sentry event captured from the webapp, so engineers can copy a trace_id from a Sentry issue and search for the corresponding trace in any OTel-aware backend. Also adds an otel_sampled tag to indicate whether the trace was head-sampled — a cheap signal for whether the link will resolve to span data or hit a missing trace.

Why

Sentry and OTel were OTel-disconnected: apps/webapp/sentry.server.ts initialised Sentry with skipOpenTelemetrySetup: true, and no error-capture site (logger.server.ts, the Remix-wrapped handleError, the root ErrorBoundary) attached OTel context to the event. With many spans/sec across services, getting from a Sentry issue to its trace was guesswork.

Approach

Single global Sentry event processor, registered immediately after Sentry.init. On each event it reads trace.getActiveSpan()?.spanContext() via @opentelemetry/api, then writes:

• event.contexts.trace.trace_id and event.contexts.trace.span_id (Sentry's native trace context fields)
• event.tags.otel_sampled = "true" | "false" (derived from traceFlags)

If no active span (module-load errors, scheduled timers without a context, primary cluster process), the processor returns the event unmodified — Sentry's default propagation context fills in.

Implementation is co-located in apps/webapp/sentry.server.ts (no separate helper module — sentry.server.ts is built standalone by esbuild and a separate import would have required a new bundling step). Helper functions are exported so the unit tests can reach them without re-running Sentry.init.

Non-goals (deliberate)

• No sample rate change. ~95% of Sentry events will carry a trace_id that returns no spans in the tracing backend (head-sampled out). The otel_sampled tag makes that obvious at a glance. Raising find-rate is a separate conversation with cost trade-offs.
• No user/org tags or Sentry.setUser (would need auth-helper + per-request scope wiring across multiple worker entrypoints — separate ticket).
• Webapp image only. No changes to supervisor or CLI workers.

Test plan

• Unit tests in apps/webapp/test/sentryTraceContext.server.test.ts — 9 tests covering: helper returns `undefined` with no active span; returns `traceId`/`spanId`/`sampled=true` for a recording span; returns `sampled=false` for a non-recording span; processor leaves the event unchanged with no active span; processor stamps `trace_id`/`span_id` onto `contexts.trace`; preserves existing `contexts.trace` fields; tags `otel_sampled` correctly for both sampled and non-sampled cases; never throws if `@opentelemetry/api` access throws.
• `pnpm run typecheck --filter webapp` passes.
• Manually verified end-to-end against a sandboxed Sentry project: confirmed both sampled and non-sampled traces correctly populate `contexts.trace.trace_id` matching the OTel ids logged from the loader, and the `otel_sampled` tag appears with the expected value.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5cfb5ad

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Caution

Review failed

Failed to post review comments

Walkthrough

The pull request adds OpenTelemetry integration to Sentry to stamp the active OTel trace_id and span_id onto Sentry events for cross-referencing with traces in any OTel backend. Two new utility functions are introduced: getActiveTraceIds() extracts the active OTel trace/span identifiers and sampling status, while addOtelTraceContextToEvent() injects this OTEL context into Sentry events as trace context and sampling tags. The integration is registered with Sentry's event processor pipeline, and comprehensive test coverage validates behavior across multiple scenarios.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: linking Sentry events to OpenTelemetry traces via trace_id, which is the core objective of this PR.
Description check	✅ Passed	The PR description is comprehensive and well-structured, covering summary, rationale, approach, non-goals, and detailed test plan. However, it lacks the required checklist items and screenshot section from the template.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch align-sentry-axiom-errors

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}