Tejal Chakeres created CASSANDRA-21531:
------------------------------------------
Summary: racing session orphaned when query execution throws
Key: CASSANDRA-21531
URL: https://issues.apache.org/jira/browse/CASSANDRA-21531
Project: Apache Cassandra
Issue Type: Bug
Reporter: Tejal Chakeres
h3. Summary
When a query throws inside execute(), the tracing session is stopped by the
finally block, but the tracing id is never attached to the response. Because
setTracingId() lives *outside* the try/finally, the throw propagates past it
and the client receives no tracing id for a session that was, in fact, opened
and closed on the server.
h3. Code path
{code:java}
try {
response = execute(queryState, requestTime, shouldTrace); // <-- throws
here
}
finally {
if (shouldTrace)
Tracing.instance.stopSession(); // session IS stopped but id not set
}
...
// unreachable on exception:
if (isTraceable() && isTracingRequested())
response.setTracingId(tracingSessionId); // SKIPPED on throw
{code}
h3. Impact
* The tracing id is lost for any failed request, so the operator/client cannot
correlate a failure with its server-side trace — exactly the case where the
trace is most useful.
* The session is opened and closed but its id never surfaces, effectively an
orphaned trace from the caller's perspective.
h3. Expected behavior
The tracing id should be propagated on the error path as well (e.g. attached to
the error response, or the exception enriched with the tracing id) so a failed,
traced query remains diagnosable. At minimum, id propagation and session
teardown should be handled consistently in the same scope.
h3. Notes
Found during review of https://github.com/apache/cassandra/pull/4936
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
