ref(server-utils): Move prisma instrumentation to server-utils#22222
Conversation
size-limit report 📦
|
| const errString = td.decode(output.stderr); | ||
| assertEquals(outString, 'App has started\n'); | ||
| assertEquals(errString, ''); | ||
| assertEquals(outString, 'App has started\n'); |
There was a problem hiding this comment.
this test caught a problem I almost introduced (accessing process.env in server-utils), great! I re-ordered the assertions here to get more details when this fails, as it would otherwise fail on "true !== false" which is not super helpful, instead of failing on the error string assertion which actually told me the problem.
| const roots = spans.filter(span => span.parentId === null); | ||
|
|
||
| for (const root of roots) { | ||
| dispatchEngineSpan(root, spans, linkIds, this.ignoreSpanTypes); | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Bug: In dispatchEngineSpan, if a parent span is ignored via ignoreSpanTypes, its entire child span subtree is also dropped, leading to incomplete traces.
Severity: MEDIUM
Suggested Fix
Modify dispatchEngineSpan to handle ignored spans differently. Instead of returning early when shouldIgnoreSpan is true, the function should skip processing the current span but still iterate over its children and recursively call dispatchEngineSpan for each one. This ensures child spans are preserved even if their parent is filtered out.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/server-utils/src/prisma/tracing-helper.ts#L189-L195
Potential issue: In the `dispatchEngineSpan` function, if a span's name matches a
pattern in the `ignoreSpanTypes` configuration, the function returns early. This
prevents the recursive processing of that span's children. As a result, if a root or
parent span is ignored, its entire subtree of child spans is also dropped, leading to
incomplete trace data. For example, ignoring a high-level `prisma:client:operation` span
would unintentionally cause its nested `prisma:engine:db_query` spans to be lost.
Did we get this right? 👍 / 👎 to inform future reviews.
This moves the prisma instrumentation code out of node into server-utils package, and reexports this as-is.
This can likely also be used in all other runtimes.
It also removes any otel dependencies, which were not even needed anymore - this does not do any monkey patching, but simply sets up a global tracing helper which prisma internally uses if found. This also allowed us to streamline the code a bit to properly handle v5-v7 compatibility in a single place.
Closes #20768