[
https://issues.apache.org/jira/browse/CASSANDRA-21527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100288#comment-18100288
]
Nivy Kani commented on CASSANDRA-21527:
---------------------------------------
For 1) and 2), it's a good catch that other callers also currently
misunderstand the return value of runWithCompactionsDisabled and hence NPE.
For submitMaximal(), it looks like compaction failures are okay (the caller
loops over multiple tables and should be idempotent) and we just want to avoid
a NPE. For releaseRepairData(), it looks like we want to treat a failed
disable-compaction as an unsuccessful cleanup.
I've made both changes to
[https://github.com/apache/cassandra/pull/4948/|https://github.com/apache/cassandra/pull/4948/changes]
and added unit tests since this was previously untested.
3) Fixed to merge throwables instead, so an error in viewManager.build() won't
replace TruncateException.
> truncateBlocking silently succeeds when runWithCompactionsDisabled returns
> null
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-21527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21527
> Project: Apache Cassandra
> Issue Type: Bug
> Reporter: Nivy Kani
> Assignee: Nivy Kani
> Priority: Normal
> Attachments: ci_summary-1.html, ci_summary.html,
> result_details.tar-1.gz, result_details.tar.gz
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, runWithCompactionsDisabled can’t tell the difference between a
> successful truncate vs a truncate that wasn’t successful due to being unable
> to stop compaction, because both return null. In either case, it logs
> “Truncate is complete” and returns success to the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
