frankvicky opened a new pull request, #22840:
URL: https://github.com/apache/kafka/pull/22840

   The test shouldExpireGroupWithoutDeleteTopologyWhenPushPermanentlyFailed 
started failing because of commit f8c9566af1 (KAFKA-20748), which deliberately 
changed the post-failure state of a Streams group.
   
   Before KAFKA-20748:
   - A permanent setTopology failure left StoredDescriptionTopologyEpoch at -1 
(NONE).
   - The cleanup scan filtered out groups with stored == NONE, so the group was 
tombstoned directly without any plugin.deleteTopology call.
   - The test's assertion assertEquals(0, deleteTopologyCalls(appId)) matched 
that invariant.
   
   After KAFKA-20748:
   1. The push path now writes an UNCERTAIN(-2) barrier to 
StoredDescriptionTopologyEpoch before calling plugin.setTopology — this is the 
durable marker that says "the plugin call is in progress; a residual entry may 
exist" (GroupCoordinatorService.java:748).
   2. When the plugin returns a permanent failure, 
setFailedDescriptionTopologyEpoch only advances FailedDescriptionTopologyEpoch; 
it deliberately leaves stored untouched (GroupMetadataManager.java:8600-8612). 
So the group ends up parked at UNCERTAIN(-2) rather than NONE(-1).
   3. The eligibility scan (GroupCoordinatorShard.java:1013-1032) now skips 
only groups whose storedEpoch == NONE, so UNCERTAIN groups are picked up.
   4. The cleanup cycle therefore issues a defensive plugin.deleteTopology on 
the group to reclaim any potentially leaked plugin entry, then tombstones the 
group.
   
   The single defensive deleteTopology call is the observed expected: <0> but 
was: <1>. This is the intended new behavior — the plugin call and the metadata 
write are non-atomic, so the broker cannot rule out a residual entry after a 
permanent failure and must reclaim it defensively.
   
   The fix was to update the test (rename + flipped assertion + refreshed 
Javadoc) to encode the new invariant: UNCERTAIN groups get a defensive 
deleteTopology before the tombstone.
   


-- 
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]

Reply via email to