Skip to content

Fix user tracing of DO SQL queries and add system tracing of them#5688

Merged
a-robinson merged 1 commit intomainfrom
arobinson/sql-tracing
Dec 15, 2025
Merged

Fix user tracing of DO SQL queries and add system tracing of them#5688
a-robinson merged 1 commit intomainfrom
arobinson/sql-tracing

Conversation

@a-robinson
Copy link
Copy Markdown
Member

The user tracing of DO SQL queries was setting the rows_read tag too soon, before the cursor actually iterated over the result rows. This lead to under-reporting of rows_read in these trace spans.

We can fix this by passing the span into the Cursor, allowing it to be finalized when the query itself is done. For some queries this will still be immediately because there aren't result rows to iterate over, but for others this will keep the span held open until either the result rows have all been read or the cursor has been canceled/closed.

There's still one case here that's a little awkward: if the query throws an exception, we don't add any tags at all (either before this change or after it). We may want to add a try-catch here that adds an error span to the traces when running the sql statement throws an exception, but we can decide on that separately since it does come involve making the code more complex and adding a bit of runtime overhead.

This is a follow-up to #5201

The user tracing of DO SQL queries was setting the rows_read tag too
soon, before the cursor actually iterated over the result rows. This
lead to under-reporting of rows_read in these trace spans.

We can fix this by passing the span into the Cursor, allowing it to be
finalized when the query itself is done. For some queries this will
still be immediately because there aren't result rows to iterate over,
but for others this will keep the span held open until either the result
rows have all been read or the cursor has been canceled/closed.

There's still one case here that's a little awkward: if the query throws
an exception, we don't add any tags at all (either before this change or
after it). We may want to add a try-catch here that adds an error span
to the traces when running the sql statement throws an exception, but we
can decide on that separately since it does come involve making the code
more complex and adding a bit of runtime overhead.
@a-robinson a-robinson force-pushed the arobinson/sql-tracing branch from 6bc8846 to 35bba0f Compare December 12, 2025 22:44
@a-robinson a-robinson merged commit 5223eb3 into main Dec 15, 2025
32 of 33 checks passed
@a-robinson a-robinson deleted the arobinson/sql-tracing branch December 15, 2025 14:11
@jmorrell-cloudflare
Copy link
Copy Markdown
Contributor

There's still one case here that's a little awkward: if the query throws an exception, we don't add any tags at all (either before this change or after it). We may want to add a try-catch here that adds an error span to the traces when running the sql statement throws an exception

In general we don't have good coverage of the various error-paths yet, or a clear way of recording errors. I would like to make progress on this soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants