mwesterby opened a new pull request, #23639: URL: https://github.com/apache/kafka/pull/23639
Updates the `KafkaZkClient` to respond appropriately when a `BADVERSION` is encountered from a write to the `/migration` znode. In the case of `updateMigrationState`, we determine if this exception is a consequence of a `ConnectionLossException` while updating the `/migration` znode. Here we read the current contents of `/migration` to determine if our write did indeed succeed and correctly recover. If not, we now throw the new `MigrationConflictException` which delegates to the `migrationConflictFaultHandler`. This will move the `KRaftMigrationDriver` to the `INACTIVE` state and renounce its leadership, allowing a new leader to be elected and continue the migration process (instead of being perpetually stuck as before). Similarly, when a `BADVERSION` is encountered as part of `handleUnwrappedMigrationResult` on the snapshot/delta update paths, we now fail with a `MigrationConflictException`, rather than a `RuntimeException`. This causes these conflicts to be delegated to the `migrationConflictFaultHandler` and be dealt with in the same way too. We cannot use the contents of `/migration` to determine if the delta/snapshot writes succeeded due to their batch design. For every non-last request, the embedded `/migration` op is a CheckOp that writes nothing itself. Only the batch's trailing SetDataOp advances the version. Confirming the `/migration`'s content matches only proves the trailing request succeeded, and none of the intermediate requests, and could leave gaps in the ZK record. Jira: https://issues.apache.org/jira/browse/KAFKA-21062 -- 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]
