Follow up from #1462.
The store tracer emits one client span per PostgreSQL statement. pgx sends BEGIN and COMMIT as normal statements, so a transaction on the request path shows as separate begin, statement and commit spans next to each other under the RPC span. This is correct but a bit noisy.
Idea from the review: wrap each transaction in one INTERNAL span and nest the statement spans under it. pgx has no hook per transaction, so this needs a small helper around pool.Begin in the store. Three call sites in cmd/ateapi/internal/store/atepg/atepg.go run on the request path. The outbox transactions run in background work without a parent span and produce no spans today.
We keep the begin and commit spans in any case. COMMIT is where the WAL flush time lands, so it carries real latency.
Follow up from #1462.
The store tracer emits one client span per PostgreSQL statement. pgx sends BEGIN and COMMIT as normal statements, so a transaction on the request path shows as separate begin, statement and commit spans next to each other under the RPC span. This is correct but a bit noisy.
Idea from the review: wrap each transaction in one INTERNAL span and nest the statement spans under it. pgx has no hook per transaction, so this needs a small helper around pool.Begin in the store. Three call sites in cmd/ateapi/internal/store/atepg/atepg.go run on the request path. The outbox transactions run in background work without a parent span and produce no spans today.
We keep the begin and commit spans in any case. COMMIT is where the WAL flush time lands, so it carries real latency.