Repository navigation
Conversation
Contributor
size-limit report 📦Compared: f271e04 (PR test merge using develop at 7aca628) Against: f948bcf (develop) · base run #64421
|
Contributor
Optional E2E testsSome optional checks were not successful. They do not block the merge. 2 not successful, 50 successful. See the run.
Successful checks
|
mydea
force-pushed
the
ref/sql-span-name
branch
2 times, most recently
from
October 30, 2026 09:08
874f60b to
2546505
Compare
mydea
changed the title
getSqlSpanName for SQL span namesgetSqlSpanName for SQL span names
mydea
force-pushed
the
ref/sql-span-name
branch
from
October 30, 2026 09:32
025b9b5 to
76b72ff
Compare
mydea
marked this pull request as ready for review
October 30, 2026 09:57
mydea
requested review from
andreiborza,
chargome,
isaacs and
nicohrubec
and removed request for
a team
October 30, 2026 09:57
mydea
force-pushed
the
ref/sql-span-name
branch
from
October 30, 2026 12:47
76b72ff to
c960c78
Compare
Every SQL integration picked the span name the same way: the query summary when spans are streamed, the sanitized statement otherwise, each with an integration-specific fallback. `getSqlSpanName` takes the query attributes and both fallbacks, and is used by mysql, mysql2, pg, knex and the Nuxt db0 integration. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Knex built its fallback span names from the operation, table and database, but those only apply when a query has no SQL, which knex practically never produces. Use the database namespace or system like the other SQL integrations instead; the operation and table stay on the span as `db.operation.name` and `db.sql.table`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With knex on the shared fallbacks, every SQL integration fell back to the database namespace and then the db system when streaming, both of which they already set as span attributes. `getSqlSpanName` now reads those from the span attributes and only takes the integration's static fallback name. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both postgres.js integrations followed the shared naming pattern by hand. The diagnostics-channel one now puts the resolved connection attributes on the span up front, so the namespace is there when naming. Tedious keeps its own names: bulk loads and procedure calls carry no statement, and the operation-based names say more than the namespace. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Only `db_query` spans go through the shared helper; other Prisma spans keep their own name even when they carry db attributes. Non-streamed Prisma 5 query spans are now named after the sanitized `db.query.text` rather than the raw `db.statement`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…neon `getSqlSpanName` only switches on span streaming because existing integrations keep their statement-based names for static spans. New integrations should always use low-cardinality names, so that half is now its own helper, which neon (always low-cardinality) uses. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mydea
force-pushed
the
ref/sql-span-name
branch
from
October 30, 2026 13:16
c960c78 to
0cc323a
Compare
nicohrubec
approved these changes
Oct 30, 2026
nicohrubec
left a comment
nicohrubec
left a comment
Member
There was a problem hiding this comment.
good cleanup and the span names changes seem alright to me
| // The attributes are already on the span; this marks the query so the `execute`/`connect` | ||
| // channels don't backfill them again. | ||
| if (context) { | ||
| setConnectionAttributes(span, query, context); |
Member
There was a problem hiding this comment.
l: iiuc the connection attributes are already set at this point and all this adds is setting the CONNECTION_ATTRS_SET marker on the query. in that case I guess we could just set the marker on the query directly and avoid some duplicate work?
| sanitizeSqlQuery, | ||
| getSqlQueryAttributes, | ||
| getSqlSpanName, | ||
| getLowCardinalitySqlSpanName, |
Member
There was a problem hiding this comment.
l: I think this as well as SqlQueryAttributes is not used outside of server-utils so we could probably omit it from the exports?
This branch has not been deployed
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.
TLDR: This PR introduces a helper to build db span names based on semantic conventions. This should make it more consistent and easier to use this in the future.
Why: We used to repeat more or less the same code in various places for building span names. Most places have a branch for legacy high-cardinality names (transactions) and low-cardinality names (streamed spans). New utilities help with that. Note that new integrations (like neon) should use the low-cardinality version only.
How to review:
getSqlSpanNameinutils/sql.ts, then skim the callsites, which now build their attributes before naming the span. Behavior changes, all limited to edge cases or improvements:db.system.namebefore'Database operation'.db_queryspans through the helper; every other Prisma span keeps its own name, even when it carries db attributes (e.g. v5'sprisma:engine:connectionhasdb.system). Fordb_queryspans:db.query.summaryfirst).db.query.text(backfilled in feat(server-utils): Move to newgetSqlQueryAttributeshelper for consistency #25927) instead of the rawdb.statement, so literals no longer end up in span names, e.g.… WHERE 1=1 …becomes… WHERE ?=? …. Prisma 6+ already uses Prisma's owndb.query.text, so nothing changes there.db_queryspan with no SQL at all would now fall back todb.namespace/db.system.namebefore the Prisma span name. Prisma doesn't emit query spans without SQL in practice.Unsure about: Tedious keeps its own names on purpose (see the comment there): bulk loads and procedure calls have no statement, and operation-based names say more than the namespace.
Stacked on #25927.
🤖 Generated with Claude Code