[WIP] fix(node): Capture Prisma v5 engine spans under the SentryTracerProvider#21867
Draft
andreiborza wants to merge 1 commit into
Draft
[WIP] fix(node): Capture Prisma v5 engine spans under the SentryTracerProvider#21867andreiborza wants to merge 1 commit into
andreiborza wants to merge 1 commit into
Conversation
Contributor
size-limit report 📦
|
ab6fac9 to
db893dc
Compare
f67d8bd to
ddfd706
Compare
db893dc to
e7deffe
Compare
ddfd706 to
6f37f91
Compare
e7deffe to
c2ffa6d
Compare
34472ac to
00bddb6
Compare
aab7745 to
d506cee
Compare
c635e74 to
bbac34a
Compare
f553a31 to
83debe2
Compare
bbac34a to
78daa6e
Compare
78daa6e to
55b71c3
Compare
83debe2 to
be9048a
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 55b71c3. Configure here.
55b71c3 to
053dbdf
Compare
be9048a to
134ffbc
Compare
053dbdf to
1818744
Compare
a9b926a to
cdede48
Compare
1818744 to
4ac0a46
Compare
Prisma v5 engine spans (`prisma:engine:*`, which carry the SQL `db.statement`) were minted by hijacking the OTel SDK tracer's private `_idGenerator`. The SentryTracerProvider's tracer has no `_idGenerator`, so the shim bailed and dropped every engine span, leaving only the `prisma:client:*` spans. Replace the hack with a span registry: client spans register by their span id on `spanStart`, and each v5 engine span is created under the parent it references by id via `startInactiveSpan`. Engine spans whose parent hasn't been seen yet wait in a pending buffer until a later batch registers it, reproducing the flat `parent_span_id` regrouping the OTel SDK exporter used to do. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4ac0a46 to
9e9591e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Prisma v5 engine spans (
prisma:engine:*, which carry the SQLdb.statement) were dropped under theSentryTracerProvider, leaving only theprisma:client:*spans in the transaction. This re-enables the Prisma v5 integration test and fixes the regression.Root cause
The v5 compatibility shim minted engine spans by hijacking the OTel SDK tracer's private
_idGeneratorto stamp the engine's exact span/trace ids, then relied on the SDK exporter regrouping spans byparent_span_idat flush. TheSentryTracerProvider's tracer has no_idGenerator(so the shim bailed out and dropped every engine span), and it assembles transactions from the live_childrentree rather than regrouping a flat list.Fix
A bounded
spanId -> Spanregistry. Client spans register onspanStart; each v5 engine span is created under the parent it references by id viastartInactiveSpan. Because v5 dispatches engine spans detached and out of order (a child can arrive before its parent), a span whose parent isn't registered yet waits in a pending buffer until a later batch registers it. This reproduces the exporter's flatparent_span_idregrouping for the provider path, and removes the fragile_idGeneratorhack.WIP / draft: stacked on #21680 to validate on CI. To be reworked into a standalone PR against
develop(the fix is provider-agnostic; the OTel SDK /openTelemetryBasicTracerProviderpath still needs validating there).