Repository navigation
feat(server-utils): Extract getSqlSpanName for SQL span names - #25929
Merged
Merged
Conversation
Contributor
size-limit report 📦Compared: 2ad1ebc (PR test merge using develop at 2619fa4) Against: 2619fa4 (develop) · base run #64952 ✅ Baseline matches: this diff contains only this PR's changes.
|
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
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
chargome
approved these changes
Nov 3, 2026
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>
…t span start The resolved connection attributes are already passed to the span when it is created, as naming needs the namespace up front, so setting them again right after was redundant. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A query reaches only one of the `execute` and `connect` channels with a connection, so nothing is left for the marker to guard now that span start no longer sets it. Also simplifies `deferSpanEnd` and inlines two small helpers that were left with a single purpose. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e helpers `getLowCardinalitySqlSpanName` and `SqlQueryAttributes` are only used inside `@sentry/server-utils`, whereas Nuxt needs `getSqlSpanName`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…points Existing scenarios use a single endpoint, which the integration resolves when the span starts, so nothing exercised the `execute` and `connect` channels that attach the attributes when several endpoints are known. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mydea
force-pushed
the
ref/sql-span-name
branch
from
November 4, 2026 10:33
0cc323a to
3e5327f
Compare
mydea
added a commit
that referenced
this pull request
Nov 4, 2026
**Why:** The postgres.js integration and the portable `instrumentPostgresJsSql` wrapper each had their own copy of the logic that ends a span when a query settles. This moves it into one helper and gives it direct unit tests, which it didn't have before. **How to review:** Start with `_wrapQuerySettlement` in `postgresjs-wrapper.ts`, which is the integration's existing function plus an `onSettle` callback for its `SPAN_ENDED` flag. The integration side should behave the same. The wrapper changes slightly: it uses plain functions instead of Proxies (the callbacks have no properties to forward), a missing callback no longer throws, and its debug messages use the `[instrumentation:postgresjs]` prefix. **Unsure about:** No integration or e2e test calls `instrumentPostgresJsSql`, so the wrapper's side is only covered by unit tests. Stacked on #25929. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
51 tasks done
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