ref(node): Streamline Prisma v5 instrumentation#21980
Merged
Merged
Conversation
Reworks the Prisma v5 engine-span compatibility shim off the OTel SDK tracer's private `_idGenerator` and onto Sentry's provider-agnostic span APIs, the v5 counterpart of #21819 (v6/v7). The `SentryTracerProvider` is now the default tracer provider. Its `SentryTracer` creates native Sentry spans and has no `_idGenerator`, so the v5 shim bailed and dropped every `prisma:engine:*` span, leaving only the `prisma:client:*` spans. Engine spans are now minted via `startInactiveSpan`, reparented by id through a bounded registry plus a pending buffer that resolves spans Prisma dispatches out of order across batches. This works under both the default `SentryTracerProvider` and the opt-in OTel `BasicTracerProvider`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
andreiborza
requested review from
JPeer264 and
mydea
and removed request for
a team,
JPeer264 and
mydea
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
mydea
approved these changes
Jul 6, 2026
Contributor
size-limit report 📦
|
Member
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
s1gr1d
approved these changes
Jul 6, 2026
Comment on lines
-113
to
-121
| const links: Link[] | undefined = engineSpan.links?.map(link => { | ||
| return { | ||
| context: { | ||
| traceId: link.trace_id, | ||
| spanId: link.span_id, | ||
| traceFlags: TraceFlags.SAMPLED, | ||
| }, | ||
| }; | ||
| }); |
Member
There was a problem hiding this comment.
It's probably more complicated to still add the links - but they are dropped in the new version, am I seeing this correctly?
Member
There was a problem hiding this comment.
edit: I see they are already added
Comment on lines
+88
to
+91
| const parentSpan = prismaSpanRegistry.get(engineSpan.parent_span_id); | ||
| if (!parentSpan) { | ||
| continue; | ||
| } |
Member
There was a problem hiding this comment.
Q: Could it be a problem that spans without parent spans are kept in the prismaSpanRegistry?
Member
Author
There was a problem hiding this comment.
Should not, at most we keep 1000 spans around in memory but that has already been the case before too. I think for the streamlining effort this fine and we could consider improving this if it's an actual problem. It's unlikely that we end up with spans without parent spans here, but if this will be an issue we can look at evicting this automatically or something like that.
Member
Author
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 66be130. Configure here.
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
3 participants
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.
Reworks the Prisma v5 engine-span compatibility shim off the OTel SDK tracer's private
_idGeneratorand onto Sentry's provider-agnostic span APIs. This is the v5 counterpart of #21819 (which streamlined v6/v7).Engine spans are now minted via
startInactiveSpan, reparented by id through a boundedLRUMapregistry plus apendingEngineSpansbuffer that resolves spans Prisma dispatches out of order across batches. The v5 integration test is re-enabled and aBasicTracerProvidervariant is added, so v5 is verified under both the defaultSentryTracerProviderand the opt-in OTelBasicTracerProvider(openTelemetryBasicTracerProvider: true).Root cause: The
SentryTracerProviderbecame the default tracer provider. ItsSentryTracercreates native Sentry spans and has no_idGenerator, so the v5 shim (which hijacked that private field to mint spans with the engine's exact ids) hit its guard, warned, and dropped everyprisma:engine:*span, leaving only theprisma:client:*spans.Closes: #21821