adixitconfluent commented on PR #19786:
URL: https://github.com/apache/kafka/pull/19786#issuecomment-2907739810
> @adixitconfluent Simply adding that kinds of line is not sufficient. Since
tp3 is not in sharePartitionManager.partitionCache, but returned in
cachedTopicIdPartitionsInShareSession. Currently, In Following codes of
SharePartitionManager.java, exceptions occurs.
>
> ```
> List<TopicIdPartition> topicIdPartitions =
cachedTopicIdPartitionsInShareSession(
> groupId, memberIdUuid); // tp3 is included.
>
> ...
>
> topicIdPartitions.forEach(topicIdPartition -> {
> SharePartitionKey sharePartitionKey = sharePartitionKey(groupId,
topicIdPartition);
>
> SharePartition sharePartition =
partitionCache.get(sharePartitionKey); // In partitionCache, no tp3
> if (sharePartition == null) {
> // this exception is called.
> log.error("No share partition found for groupId {}
topicPartition {} while releasing acquired topic partitions", groupId,
topicIdPartition);'
> ```
>
> There are two options we can choose.
>
> 1. add tp3 in sharePartitionManager.partitionCache and make mock behaviors
for it.
> 2. do nothing and see if exception is detected and handled well.
>
> I guess 2 is the better choice, since I see this is intentional like
testReleaseSessionSuccess.
@ji-seung-ryu , the point of this test is to test that delayed share fetch
requests are completed for the given watch keys when release session API is
called for any group member. So, considering that, I think you should add tp3
to partition cache map and then mock `releaseAcquiredRecords` for tp3 as I
mentioned
[here](https://github.com/apache/kafka/pull/19786#issuecomment-2906971134).
Basically, option 1 of your comment.
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
