belliottsmith commented on code in PR #65:
URL: https://github.com/apache/cassandra-accord/pull/65#discussion_r1442871593
##########
accord-core/src/main/java/accord/messages/Commit.java:
##########
@@ -275,6 +275,22 @@ public static void commitInvalidate(Node node, TxnId
txnId, Unseekables<?> infor
// TODO (expected, safety): this kind of check needs to be
inserted in all equivalent methods
Invariants.checkState(untilEpoch >= txnId.epoch());
Invariants.checkState(node.topology().hasEpoch(untilEpoch));
+ // Possible that the invalidation is due to the range no longer
existing in untilEpoch, which means that
Review Comment:
So a couple of thoughts here:
1) How can this happen? We should only invoke with an `untilEpoch` we
attempted to `Accept` with, and we shouldn't attempt to `Accept` in an epoch
where the keys don't exist
2) If we have somehow done this, I think it is fine to contact `untilEpoch`
even if some keys are missing? The problem with going to the earliest epoch we
can fine that contains them is that if we have somehow gone into a future
epoch, we might have left traces we should ideally invalidate for other keys
that did still exist, and have moved replica
My preference would be to first figure out (1), as if it's happening it may
indicate some other issue that we can address. Then we might anyway want to
support a version of `preciseEpochs` that permits topology mismatches.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
