KAFKA-19630: Reordered OR operands in archiveRecords method for SharePartiton #20391
+118
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… method so that short-circuit does not prevent archiving necessary records / batches
github-actions
bot
added
triage
chirag-wadhwa5
changed the title
chirag-wadhwa5
changed the title
chirag-wadhwa5
changed the title
chirag-wadhwa5
changed the title
chirag-wadhwa5
changed the title
chirag-wadhwa5
changed the title
apoorvmittal10
changed the title
Contributor
apoorvmittal10
left a comment
apoorvmittal10
left a comment
There was a problem hiding this comment.
LGTM! I have suggested to add 1 more validation in the test.
Comment on lines
+4523
to
+4524
| // Note, the records that are in ACQUIRED state will remain in ACQUIRED state and will be transitioned to a Terminal | ||
| // state when the corresponding acquisition lock timer task expires. |
Contributor
There was a problem hiding this comment.
In the end of this current method:
Can you call sharePartition.acknowledge(MEMBER_ID, List.of(new ShareAcknowledgementBatch(21L, 30L, List.of((byte) 2)))). Validate the response and cached state. This will make sure that acknowledge did nothing and also didn't fail. However, I ll discuss this behaviour in a separate PR, when I ll update the method docs.
Then call sharePartition.cachedState().get(21L).batchAcquisitionLockTimeoutTask().run(); and validate the respective records are directly archived.
Collaborator
Author
There was a problem hiding this comment.
Thanks for the review. I have made the required changes in the latest commit.
apoorvmittal10
approved these changes
Aug 21, 2025
Contributor
apoorvmittal10
left a comment
apoorvmittal10
left a comment
There was a problem hiding this comment.
LGTM! Build is failing though.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As per the current implementation in archiveRecords, when LSO is
updated, if we have multiple record batches before the new LSO, then
only the first one gets archived. This is because of the following lines
of code ->
isAnyOffsetArchived = isAnyOffsetArchived || archivePerOffsetBatchRecords(inFlightBatch, startOffset, endOffset - 1, initialState);isAnyBatchArchived = isAnyBatchArchived || archiveCompleteBatch(inFlightBatch, initialState);The first record / batch will make
isAnyOffsetArchived/isAnyBatchArchivedtrue, after which this line of code willshort-circuit and the methods
archivePerOffsetBatchRecords/archiveCompleteBatchwill not be called again. This PR changes theorder of the expressions so that the short-circuit does not prevent from
archiving all the required batches.
Reviewers: Apoorv Mittal apoorvmittal10@gmail.com