Skip to content

Reproduction for sentry-javascript#18572#26

Open
andreiborza wants to merge 4 commits intomainfrom
repro/sentry-javascript-18572
Open

Reproduction for sentry-javascript#18572#26
andreiborza wants to merge 4 commits intomainfrom
repro/sentry-javascript-18572

Conversation

@andreiborza
Copy link
Member

@andreiborza andreiborza commented Feb 27, 2026

Summary

Reproduction for getsentry/sentry-javascript#18572

OpenTelemetry context not propagating correctly when using @sentry/nestjs with custom OTel setup (skipOpenTelemetrySetup: true) and SentryContextManager. Traces randomly break into multiple partial traces under load, especially with gRPC endpoints.

Reproduction result

100% of spans are orphaned — zero correctly-parented spans. The SentryContextManager completely loses context propagation under concurrent gRPC traffic across multiple microservices.

Setup (matches reporter's production config)

  • NestJS hybrid app (HTTP + two gRPC microservices on separate ports)
  • Sentry + custom OTel SDK with SentryContextManager, SentryPropagator, SentrySpanProcessor
  • skipOpenTelemetrySetup: true with manual OTel configuration
  • Custom sampler using wrapSamplingDecision (health-check filter)
  • connectMicroservice() with inheritAppConfig: false
  • Double exporter registration (top-level traceExporter + inside BatchSpanProcessor)
  • loader: { defaults: true } in gRPC options
  • ContextDebugSpanProcessor that logs ORPHAN vs PARENTED spans (capped at 10 each)
  • Test client with ramping concurrent waves hitting all endpoints

How to run

cd sentry-javascript/18572
npm install
npx nest build
node dist/instrument.js
# In another terminal:
node dist/test-client.js

Check server logs for [CONTEXT-DEBUG] lines — you'll see only ORPHAN entries and zero PARENTED entries.

Key findings

  • The bug reproduces locally with this setup (reporter could not reproduce locally before)
  • Every single span ends up orphaned — not just some, all of them
  • The /test-cross-service endpoint (concurrent calls to both hero and villain gRPC services) is the most realistic trigger
  • Context is already lost at span creation time, not just at end time

Notes

  • Regression introduced between v10.25.0 and v10.27.0
  • Suspected related to #18178 / PR #18239
  • Disabling Sentry entirely fixes the issue; removing tracesSampleRate/SentrySpanProcessor does not

andreiborza and others added 3 commits March 6, 2026 10:47
Based on getsentry/sentry-javascript#18572 (comment):

- Add second gRPC microservice (villain) on separate port (5002)
- Use `inheritAppConfig: false` on both connectMicroservice calls
- Add `loader: { defaults: true }` to gRPC options
- Register traceExporter both as top-level and in BatchSpanProcessor (duplicating reporter's setup)
- Add `/test-cross-service` endpoint for cross-service call patterns
- Increase test client concurrency with ramping waves up to 100 concurrent requests

Agent transcript: https://claudescope.sentry.dev/share/p0PKCnaM4X-PXwNqNurK_NZcF-DFYk6cfB8x4CcIfYY
…SpanExporter

Replaces verbose per-span logging with capped ORPHAN/PARENTED counters
(10 each) to make output readable. Removes ConsoleSpanExporter that was
flooding logs. Result: 100% of spans are orphaned, confirming the
context propagation bug is fully reproduced.

Agent transcript: https://claudescope.sentry.dev/share/6Z9fxEpUGfJ4PxxU4WoJbZPSQ9Y5tZsy86c4WwRQkjc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants