Open per-query tracing span in QueryLogger#4270
Open
Diggsey wants to merge 1 commit into
Open
Conversation
QueryLogger now opens a hardcoded INFO-level `db.query` span in `new()` that closes on drop, with field names following the OTel database span semantic conventions (`db.system.name`, `db.query.text`, `db.response.returned_rows`, `db.response.affected_rows`, `otel.kind = "client"`). The existing close-time event is emitted inside the span via `Span::in_scope` so callers get both — the span for OTel correlation, the event for the existing `rows_affected`/`elapsed_secs` fields under whatever level `LogSettings` configures. `QueryLogger::new` keeps its old signature; drivers attach the system name via the additive `with_db_system_name` builder, which records the `db.system.name` attribute on the already-open span. QueryLogger stores `Span`, not `EnteredSpan`, so it stays `Send` across the postgres/mysql `try_stream!` paths that broke launchbadge#3176. A small `InstrumentedStream` wrapper (using `pin-project-lite`, already present transitively via the async runtimes) enters the span on each `poll_next` and drops the guard before returning, so no guard is held across an await. SQLite's synchronous `Iterator` path just relies on the close-event in-scope emission. Design constraints come from abonander's 2026-04-14 review on launchbadge#3313: current OTel semconv field names, no `tracing::enabled!()` (broken per tokio-rs/tracing#2448), hardcoded verbosity rather than runtime- configurable span levels.
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.
QueryLogger now opens a hardcoded INFO-level
db.queryspan innew()that closes on drop, with field names following the OTel database span semantic conventions (db.system.name,db.query.text,db.response.returned_rows,db.response.affected_rows,otel.kind = "client"). The existing close-time event is emitted inside the span viaSpan::in_scopeso callers get both — the span for OTel correlation, the event for the existingrows_affected/elapsed_secsfields under whatever levelLogSettingsconfigures.QueryLogger::newkeeps its old signature; drivers attach the system name via the additivewith_db_system_namebuilder, which records thedb.system.nameattribute on the already-open span.QueryLogger stores
Span, notEnteredSpan, so it staysSendacross the postgres/mysqltry_stream!paths that broke #3176. A smallInstrumentedStreamwrapper (usingpin-project-lite, already present transitively via the async runtimes) enters the span on eachpoll_nextand drops the guard before returning, so no guard is held across an await. SQLite's synchronousIteratorpath just relies on the close-event in-scope emission.Design constraints come from abonander's 2026-04-14 review on #3313: current OTel semconv field names, no
tracing::enabled!()(broken per tokio-rs/tracing#2448), hardcoded verbosity rather than runtime- configurable span levels.Does your PR solve an issue?
It's related to a number of issues but doesn't directly solve one.
Is this a breaking change?
No
This PR was written with assistance from Claude Code