sql.rows span don't correlate to sql.conn.query

[luis-mozn]

Description

Not sure if this is a bug or intended behavior, but currently when a single application span does multiple queries with QueryContext concurrently. We get 2 sibling spans per query: a sql.conn.query which contains the useful information like the sql annotation, and a sql.rows which is where the time taken actually goes to.

Right now it doesn't look like we can easily tell which query relates to which rows call and I wasn't sure from the code whether this is intentional or not - by passing queryCtx in newRows we should get a child span although they are different operations. Alternatively a way to set the query string on rows span would be nice.

Environment

• OS: Alpine Linux
• Architecture: x86
• Go Version: 1.25.0
• otelsql version: v0.40.0

Steps To Reproduce

Concurrently create multiple QueryContext calls and read all rows from them. Should get multiple sibling spans with no correlation between them

Expected behavior

There should be a way to know which query originated which rows call

[luis-mozn]

I found #108 which explains the rationale for keeping these as siblings. But in this case I'd propose to have the sql tag in the rows call as well. Or at least a way to configure the behavior

(Edit: can't change the label now from Bug to enhancement)

[XSAM]

Could you elaborate more about sql tag in the rows or the enhancement? I am not sure what it is.

[luis-mozn]

@XSAM thanks for the quick reply. I'm referring to the db.statement attribute of the span that contains the sql query. When newRows is called, it always passes query as an empty string when creating the span:

otelsql/rows.go

Line 50 in e97cfff

_, span = createSpan(ctx, cfg, method, false, "", nil)

My proposal is that we pass the queryString from QueryContext (

otelsql/conn.go

Line 157 in e97cfff

rows, err = queryer.QueryContext(queryCtx, c.cfg.SQLCommenter.withComment(queryCtx, query), args)

) and add this attribute to the rows span as well - potentially disabled by default but configurable.

The benefit would be to avoid potential situations like this if you have multiple go routines loading data without one application span per query:

Right now the useful metadata is in sql.conn.query span but the time taken can be in sql.rows

WDYT?

[XSAM]

@luis-mozn Are you saying putting db.statement attribute into sql.rows spans? This does not build the causality between sql.conn.query spans and sql.rows spans.

---

I am thinking of adding an option to propagate trace context from query to row to solve this problem and bring causality. But this would bring a weird span structure mentioned here.

[luis-mozn]

@XSAM it's not a direct causality but it makes the rows span more useful than it current is.

That second approach was my original suggestion but from the linked issue I assumed it had already been discarded.

From my perspective both approaches are reasonable. The only alternative I see would be a parent span that encompasses both the query and rows calls but unless done manually at the application level explicitly it seems like it could be misleading

[XSAM]

That second approach was my original suggestion but from the linked issue I assumed it had already been discarded.

I have being thinking this for a while, and this approach seems a better user experience. I am planning to implement this.