[
https://issues.apache.org/jira/browse/CASSANDRA-21710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118619#comment-18118619
]
Francisco Guerrero commented on CASSANDRA-21710:
------------------------------------------------
Patch for 6.0: https://github.com/apache/cassandra/pull/5205
[^CASSANDRA-21710-cassandra-6.0-ci_summary.html]
Patch for trunk: https://github.com/apache/cassandra/pull/5199
[^CASSANDRA-21710-trunk-ci_summary.html]
Errors in the run are unrelated to this change
> Preserve the original exception when an in-memory local response fails to
> close
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-21710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21710
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Local/Other
> Reporter: Francisco Guerrero
> Assignee: Francisco Guerrero
> Priority: Normal
> Fix For: 6.0-alpha3, 7.0
>
> Attachments: CASSANDRA-21710-cassandra-6.0-ci_summary.html,
> CASSANDRA-21710-trunk-ci_summary.html
>
>
> {{InMemoryDataResponse.build}} closes the row iterator in a finally block, so
> a failure from {{iter.close()}} will shadow the already in-flight exception.
> In the test where I noticed this issue, a read aborted by
> {{ReadCommand.QueryCancellationChecker}} leaves a partition that can end on
> an open range tombstone bound, which the {{PROCESSED RTBoundValidator}}
> rejects on close. The client is seeing a {{ReadFailureException}} instead of
> a {{ReadTimeoutException}}. We should instead accumulate the failures into
> the current exception, mirroring what the serialized path already does by
> closing through try-with-resources.
> This behavior change was introduced in CASSANDRA-21354
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
