Skip to content

KAFKA-19164: Keep track of groups when deleting transactional offsets #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: trunk
Choose a base branch
from

Conversation

arvi18
Copy link

@arvi18 arvi18 commented Apr 21, 2025

When deleting pending transactional offsets, we must preserve the list
of groups associated with the producer ID, otherwise we cannot clean up
the list of pending transactions for the group once the transaction is
committed or aborted.

Summary by CodeRabbit

  • Bug Fixes

    • Enhanced offset management to retain empty group entries for pending transactional offsets while removing them appropriately for regular offsets, improving group cleanup accuracy.
  • Tests

    • Added a test validating cleanup behavior when pending transactional offsets are deleted before commit, ensuring groups are deleted only when safe.

When deleting pending transactional offsets, we must preserve the list
of groups associated with the producer ID, otherwise we cannot clean up
the list of pending transactions for the group once the transaction is
committed or aborted.
Copy link

coderabbitai bot commented Apr 21, 2025

Walkthrough

The changes introduce a new boolean parameter, preserveGroups, to the Offsets inner class within OffsetMetadataManager. This parameter determines whether empty group entries are retained when offsets are removed. The main offsets store now removes empty groups as before, while pending transactional offsets retain them to track ongoing transactions. The control flow for replaying offset commits with a producer id is updated to accommodate this behavior. Additionally, a new test is added to verify the cleanup logic when pending transactional offsets are deleted before a transaction is committed.

Changes

File(s) Change Summary
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/OffsetMetadataManager.java Added preserveGroups parameter and logic to the Offsets class; updated control flow for offset removal and replay.
group-coordinator/src/test/java/org/apache/kafka/coordinator/group/OffsetMetadataManagerTest.java Added a new test method to verify cleanup of expired offsets with deleted pending transactional offsets.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant OffsetMetadataManager
    participant Offsets
    participant Group

    Client->>OffsetMetadataManager: Commit offset (with/without producer id)
    OffsetMetadataManager->>Offsets: Add/update offset (preserveGroups depends on context)
    Client->>OffsetMetadataManager: Delete offset (possibly pending transactional)
    OffsetMetadataManager->>Offsets: Remove offset
    Offsets-->>OffsetMetadataManager: Conditionally remove group entry (based on preserveGroups)
    OffsetMetadataManager->>Group: Check if group can be deleted
Loading

Poem

In the warren of offsets, a flag now appears,
To keep empty groups, or sweep them with cheers.
Transactions in limbo, their groups still remain,
Until all is settled, then cleaned up again.
A test hops along, to check every case—
The rabbit approves, with a whisker of grace! 🐇


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite

📥 Commits

Reviewing files that changed from the base of the PR and between ed79212 and d670f68.

📒 Files selected for processing (2)
  • group-coordinator/src/main/java/org/apache/kafka/coordinator/group/OffsetMetadataManager.java (4 hunks)
  • group-coordinator/src/test/java/org/apache/kafka/coordinator/group/OffsetMetadataManagerTest.java (1 hunks)
🔇 Additional comments (18)
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/OffsetMetadataManager.java (15)

201-205: Well-documented change to support preserving empty group entries.

This new field is clearly documented, explaining why empty group entries need to be preserved specifically for pending transactions.


212-214: Constructor parameter properly captures and stores the preserveGroups flag.

The constructor is appropriately updated to accept and store the new boolean flag.


266-267: Key implementation of conditional group retention logic.

This change implements the core logic that conditionally retains empty group entries when preserveGroups is true, which is necessary for tracking groups with pending transactions even after their offsets are deleted.


288-288: Main offsets storage correctly initialized with preserveGroups=false.

The main offsets store is initialized with preserveGroups=false, maintaining the previous behavior of removing empty groups, which is appropriate for non-transactional offsets.


1005-1005: Pending transactional offsets correctly initialized with preserveGroups=true.

The pending transactional offsets are now created with preserveGroups=true, ensuring that group entries are preserved even when all offsets for a given topic are removed. This is essential for the proper handling of transaction lifecycles.


201-205: Well-documented boolean flag addition

The flag's purpose is clearly documented, explaining that it's used to track groups associated with pending transactions.


212-214: Constructor modification looks good

Properly updated the constructor to accept the new parameter and initialize the field.


266-267: Correct conditional modification

Good implementation that only removes the group entry if preserveGroups is false and the topicOffsets are empty. This ensures we keep track of groups with pending transactions even if all their offsets are removed.


288-288: Appropriate default value for main offsets store

The main offsets store uses preserveGroups=false, maintaining the existing behavior of removing empty groups.


1004-1005: Correct implementation for pending transactional offsets

Using preserveGroups=true for pendingTransactionalOffsets ensures we track the groups associated with ongoing transactions, even if all their offsets are deleted.


201-205: Appropriate addition of preserveGroups field with clear documentation

The addition of this boolean field with clear documentation explains the purpose of maintaining empty group entries when tracking transactional offsets, which aligns well with the PR objective.


212-214: LGTM: Constructor updated to accept the new parameter

The constructor has been properly updated to accept and initialize the new preserveGroups parameter.


266-267: Proper conditional removal of groups based on preserveGroups flag

This change ensures that empty groups are only removed when preserveGroups is false, which addresses the core issue of the PR - keeping track of groups when deleting transactional offsets.


288-289: Correctly initializing the main offsets store with preserveGroups=false

This maintains the existing behavior for the main offsets store while allowing the pending transactional offsets to use a different behavior.


1004-1006: Correctly initializing pending transactional offsets with preserveGroups=true

This is the critical change that ensures pending transaction groups are preserved even when all offsets for that group are removed, which will allow proper clean-up once the transaction is committed or aborted.

group-coordinator/src/test/java/org/apache/kafka/coordinator/group/OffsetMetadataManagerTest.java (3)

2596-2655: Comprehensive test for handling deleted pending transactional offsets.

This test verifies a critical use case: when pending transactional offsets are deleted before a transaction is committed, the group should not be deleted until the transaction is properly committed and the retention period has passed.

The test adequately covers:

  1. Setting up a regular offset and a pending transactional offset
  2. Explicitly deleting the pending transactional offset
  3. Verifying the group isn't immediately deletable (still has a pending transaction)
  4. Committing the transaction and verifying the group becomes deletable

This test is important to ensure the proper lifecycle of groups with pending transactions, even after their offsets are deleted.


2596-2655: Well-designed test for the new functionality

This test thoroughly verifies the behavior when pending transactional offsets are deleted before a transaction is committed:

  1. It confirms a tombstone record is produced when deleting the pending offset
  2. It verifies the group isn't deleted (correctly returning false) after time passes because there's still a pending transaction
  3. It validates that after the transaction is committed and time passes again, the group becomes eligible for deletion (returning true)

The test effectively covers the new edge case addressed by the PR, ensuring that groups with deleted pending transactional offsets are still tracked until the transaction completes.


2596-2655: Well-designed test for the new functionality

This test comprehensively validates the new behavior by:

  1. Setting up both regular and pending transactional offsets
  2. Explicitly deleting the pending transactional offset
  3. Verifying that the group is not deletable due to the ongoing transaction
  4. Committing the transaction and verifying that the group becomes deletable afterward

The test ensures that the implementation correctly preserves groups associated with pending transactions even when their offsets are explicitly deleted, which is exactly the issue addressed by this PR.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@visz11
Copy link
Collaborator

visz11 commented Apr 21, 2025

@coderabbitai full review

Copy link

coderabbitai bot commented Apr 21, 2025

✅ Actions performed

Full review triggered.

@visz11
Copy link
Collaborator

visz11 commented Apr 23, 2025

@coderabbitai full review

Copy link

coderabbitai bot commented Apr 23, 2025

✅ Actions performed

Full review triggered.

@visz11
Copy link
Collaborator

visz11 commented Apr 24, 2025

/gemini review

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

The pull request introduces a mechanism to preserve group information when deleting transactional offsets, which is crucial for cleaning up pending transactions. The changes seem well-structured and include a new test case to validate the cleanup behavior. Overall, the changes look good, but I have a few suggestions for improvement.

Summary of Findings

  • Clarity of 'preserveGroups' usage: The purpose of the preserveGroups flag could be made more explicit in the Offsets class constructor to improve readability.
  • Test case description: The test case testCleanupExpiredOffsetsWithDeletedPendingTransactionalOffsets could benefit from a more descriptive name or additional comments to clarify its purpose.

Merge Readiness

The changes appear to be well-implemented and include a new test case. However, addressing the comments regarding the clarity of preserveGroups and the test case description would further improve the quality of the code. I am unable to directly approve the pull request, and recommend that others review and approve this code before merging. I recommend that the pull request not be merged until the high severity issues are addressed (at a minimum).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants