You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Delay EXECUTE_STATEMENT metric emission to rows.Close()
Previously AfterExecute/CompleteStatement fired when QueryContext()
returned — before the user ever called rows.Next(). This meant
chunk_count was always 1 and all per-chunk timing fields were null,
because fetchResultPage() calls happen during row iteration.
Fix:
- Add FinalizeLatency() to Interceptor: captures elapsed time at
QueryContext return to preserve execute-only latency in mc.
- AfterExecute() uses the pre-captured latency if available, so the
metric reports server-exec+poll time regardless of when it fires.
- Move AfterExecute/CompleteStatement from a defer in QueryContext to
closeCallback, which rows.Close() invokes after all rows are read.
At that point chunk_count and all timing tags are fully accumulated.
- Error path: still emits EXECUTE_STATEMENT immediately on runQuery
failure (no rows means no chunks to wait for).
Co-authored-by: Isaac
0 commit comments