Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NextJS Pages API Route traces are not continued from incoming trace #14787

Closed
3 tasks done
Lms24 opened this issue Dec 18, 2024 · 4 comments · Fixed by #14813
Closed
3 tasks done

NextJS Pages API Route traces are not continued from incoming trace #14787

Lms24 opened this issue Dec 18, 2024 · 4 comments · Fixed by #14813
Assignees
Labels
Package: nextjs Issues related to the Sentry Nextjs SDK

Comments

@Lms24
Copy link
Member

Lms24 commented Dec 18, 2024

Is there an existing issue for this?

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

8.46.0

Framework Version

NextJS 15.1.1

Link to Sentry event

N/A

Reproduction Example/SDK Setup

Clone my repro: https://github.com/Lms24/nextjs-trace-envelope-header

Steps to Reproduce

To reproduce:

  1. npm install
  2. npm run build && npm run start
  3. sh req.sh

Observe that trace_id, sample_rate and transaction fields (+others) are not continued from incoming trace (see req.sh). Meaning, it seems like the NextJS SDK starts a new trace for the server-side instead of continuing the passed trace via the headers.

Expected Result

  • The SDK continues the incoming trace, freezes the DSC values passed in via baggage
  • When sending its transaction event, the SDK puts the frozen DSC values into the trace envelope header and sends the continued trace data in event.context.trace

Actual Result

  • The SDK doesn't continue the incoming trace but seems to start a new trace
  • When sending its transaction event, SDK populates the DSC from the new trace and sends the new trace

Additional information

The logs suggest that there might be 2 ongoing root spans which possibly(?) conflict with each other?

Sentry Logger [log]: [Tracing] Inheriting remote parent's sampled decision for GET /api/test: true
Sentry Logger [log]: [Tracing] Starting sampled root span
  op: < unknown op >
  name: GET /api/test
  ID: 6d6d1a6095cd996c
  parent ID: 9a124d0d6c081115
Sentry Logger [log]: [Tracing] Inheriting parent's sampled decision for executing api route (pages) /api/test: true
Sentry Logger [log]: [Tracing] Starting sampled span
  op: < unknown op >
  name: executing api route (pages) /api/test
  ID: 134e7d6841094ac1
  parent ID: 6d6d1a6095cd996c
  root ID: 6d6d1a6095cd996c
  root description: GET /api/test
Sentry Logger [info]: Starting a new trace with id 1f225918b9444512867b7f0fed977fa5
Sentry Logger [log]: [Tracing] Starting sampled root span
  op: http.server
  name: GET /api/test
  ID: dfd3fc2e5a4b4818
Sentry Logger [log]: [Tracing] Finishing "http.server" root span "GET /api/test" with ID dfd3fc2e5a4b4818
Sentry Logger [log]: Flushing events...
Sentry Logger [log]: SpanExporter exported 1 spans, 0 spans are waiting for their parent spans to finish
Sentry Logger [log]: Flushing outcomes...
Sentry Logger [log]: No outcomes to send
Sentry Logger [log]: [Tracing] Finishing "< unknown op >" span "executing api route (pages) /api/test" with ID 134e7d6841094ac1
Sentry Logger [log]: [Tracing] Finishing "< unknown op >" root span "GET /api/test" with ID 6d6d1a6095cd996c
Sentry Logger [log]: SpanExporter exported 2 spans, 0 spans are waiting for their parent spans to finish
event trace context: {
  span_id: 'dfd3fc2e5a4b4818',
  trace_id: '2f656955b869439a0f839731c22cc4eb',
  data: {
    'sentry.source': 'route',
    'sentry.sample_rate': 0.99,
    'sentry.op': 'http.server',
    'sentry.origin': 'auto.http.nextjs',
    'http.response.status_code': 200
  },
  origin: 'auto.http.nextjs',
  op: 'http.server',
  status: 'ok'
}
{
  envelopeTraceHeader: {
    environment: 'production',
    release: '0UzErXa-sfDtF-53wmU7x',
    public_key: 'c64221a14c2b788162c7b81c2f94d65e',
    trace_id: '2f656955b869439a0f839731c22cc4eb',
    sample_rate: '0.99',
    transaction: 'GET /api/test',
    sampled: 'true'
  }
}
Sentry Logger [log]: Event processor "NextLowQualityTransactionsFilter" dropped event
Sentry Logger [log]: Recording outcome: "event_processor:transaction"
Sentry Logger [log]: An event processor returned `null`, will not send event.
Sentry Logger [log]: Done flushing events
@github-actions github-actions bot added the Package: nextjs Issues related to the Sentry Nextjs SDK label Dec 18, 2024
@Lms24 Lms24 changed the title NextJS Pages API Routes don't continue incoming trace NextJS Pages API Route traces are not continued from incoming trace Dec 18, 2024
@chargome
Copy link
Member

was likely introduced in #14481

Downgrading the version in the repro to 8.42.0 fixes the issue.

@Lms24
Copy link
Member Author

Lms24 commented Dec 20, 2024

Related: #14803

Update: These issues are probably not related after all

@mydea
Copy link
Member

mydea commented Dec 20, 2024

Wait, I found the problem! I will open a PR to fix this 😬 We are using continueTrace from @sentry/core there, but we have to use the one from @sentry/opentelemetry. This sucks, we should probably put this on the ACS...

@lforst
Copy link
Member

lforst commented Dec 20, 2024

@mydea Additional thing to consider, we cannot use the opentelemetry continueTrace() there because this is runtime agnostic code. We actually kinda need it to be on the acs I think.

@mydea mydea closed this as completed in 65531f3 Dec 20, 2024
s1gr1d pushed a commit that referenced this issue Dec 20, 2024
…14813)

We have a different implementation of `continueTrace` for OTEL/Node.
Until now we relied on actually using the import from `@sentry/node` vs
`@sentry/core` to ensure this. However, this is a footgun, and actually
lead to a problem in NextJS because we used the core variant there.
Also, it is simply not isomorphic.

So to fix this, this PR puts `continueTrace` on the ACS so we can
consistently use the core variant in all environments.

Fixes #14787
s1gr1d pushed a commit that referenced this issue Dec 20, 2024
…14813)

We have a different implementation of `continueTrace` for OTEL/Node.
Until now we relied on actually using the import from `@sentry/node` vs
`@sentry/core` to ensure this. However, this is a footgun, and actually
lead to a problem in NextJS because we used the core variant there.
Also, it is simply not isomorphic.

So to fix this, this PR puts `continueTrace` on the ACS so we can
consistently use the core variant in all environments.

Fixes #14787
s1gr1d added a commit that referenced this issue Dec 30, 2024
…14819)

V8 backport of #14813

We have a different implementation of `continueTrace` for OTEL/Node.
Until now we relied on actually using the import from `@sentry/node` vs
`@sentry/core` to ensure this. However, this is a footgun, and actually
lead to a problem in NextJS because we used the core variant there.
Also, it is simply not isomorphic.

So to fix this, this PR puts `continueTrace` on the ACS so we can
consistently use the core variant in all environments.

Fixes #14787

Co-authored-by: Francesco Gringl-Novy <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Package: nextjs Issues related to the Sentry Nextjs SDK
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants