[
https://issues.apache.org/jira/browse/CASSANDRA-21072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18057021#comment-18057021
]
Arnav Chakraborty commented on CASSANDRA-21072:
-----------------------------------------------
Also [~brandon.williams]
Following up with more findings after digging into the code and running the
existing tests.
I looked at how DataStax handles this in their fork — they added a targeted
fix in ReadCommandVerbHandler:
{code:java}
if (!command.isTrackingWarnings() || e instanceof
TombstoneOverwhelmingException)
throw e;{code}
After tracing both code paths, I think this is the right approach. Here's why:
When the exception is re-thrown, it propagates to InboundSink.accept(), which
calls fail() → RequestFailure.forException(). This already has a mapping for
TombstoneOverwhelmingException → READ_TOO_MANY_TOMBSTONES (in
RequestFailure.java:111-112), so the coordinator receives a proper failure
response via ReadCallback.onFailure().
The current code when trackWarnings=true works around this by sending an
empty success response with TOMBSTONE_FAIL stuffed into MessageParams. The
coordinator's ReadCallback.onResponse() then has to inspect the params,
discover it's
actually a failure, and internally redirect to onFailure(). It works
(verified by running TombstoneCountWarningTest), but it's fragile and
semantically incorrect — a failure shouldn't masquerade as a success.
The other RejectException subclasses (LocalReadSizeTooLargeException,
QueryReferencingTooManyIndexesException) are fine staying on the MessageParams
path since they're designed for WarningContext aggregation across replicas.
TombstoneOverwhelmingException is a hard abort with no aggregation value, so
it should just propagate cleanly.
Happy to put up a patch adopting this approach if that aligns with the
intended fix. I'd also add a test in ReadCommandVerbHandlerTest to verify that
TombstoneOverwhelmingException is re-thrown even when warnings tracking is
enabled.
> TombstoneOverwhelmingException gets swallowed when tracking warnings
> --------------------------------------------------------------------
>
> Key: CASSANDRA-21072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21072
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Feature/Guardrails
> Reporter: Brandon Williams
> Assignee: Arnav Chakraborty
> Priority: Normal
> Fix For: 5.0.x, 6.x
>
>
> ReadCommandVerbHandler is catching RejectException and returning an empty
> response instead of propagating the failure when warnings tracking is
> enabled, see
> https://github.com/datastax/cassandra/commit/f1223ec9fd9c724f00acbe338e053f3533617c8a
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
