Why could take the method params into account ? There will be more request to the broker, but the result is the same.

Why could take the method params into account ? There will be more request to the broker, but the result is the same.

@Technoboy- I think that this is more about correctness than the possibility that the broker response might be the same in most cases. It's strictly not the same in all cases. Therefore I think that such bugs should be fixed.

Why could take the method params into account ? There will be more request to the broker, but the result is the same.

@Technoboy- I think that this is more about correctness than the possibility that the broker response might be the same in most cases. It's strictly not the same in all cases. Therefore I think that such bugs should be fixed.

This is not a bug

Why could take the method params into account ? There will be more request to the broker, but the result is the same.

@Technoboy- I think that this is more about correctness than the possibility that the broker response might be the same in most cases. It's strictly not the same in all cases. Therefore I think that such bugs should be fixed.

This is not a bug

@Technoboy- I think that depends on how you define a bug. The impact of the issue is that boolean metadataAutoCreationEnabled, boolean useFallbackForNonPIP344Brokers parameters for the getPartitionedTopicMetadata method are ignored for any other requests which are made while there's a request in progress. Let's say that the first request is made with metadataAutoCreationEnabled=false and while it's in progress a request with metadataAutoCreationEnabled=true is made. This will definitely result in an inconsistent situation. However, I agree that the likelihood that this would happen is low. Regardless of that, such issues should be fixed and I would consider them bugs. Your definition of a bug could vary and I think it's fine.

Why could take the method params into account ? There will be more request to the broker, but the result is the same.

@Technoboy- The reason we must include these parameters in the key is that they can lead to fundamentally different outcomes for the caller, breaking the API contract if not handled separately. The logic within getPartitionedTopicMetadataAsync demonstrates this.

if (!metadataAutoCreationEnabled && !clientCnx.isSupportsGetPartitionedMetadataWithoutAutoCreation()) {
    if (useFallbackForNonPIP344Brokers) {
        // Fall back to old behavior
        finalAutoCreationEnabled = true;
    } else {
        // This path fails immediately
        partitionFuture.completeExceptionally(new PulsarClientException.FeatureNotSupportedException(...));
        return;
    }
}
// This path sends a request to the broker
ByteBuf request = Commands.newPartitionMetadataRequest(topicName.toString(), requestId, finalAutoCreationEnabled);

Here is a practical example of why caching them separately is critical, as two calls with the same TopicName but different parameters can produce completely different results:

• When the broker does not support PIP-344, the outcome depends entirely on the useFallbackForNonPIP344Brokers flag:

  • One call might fail immediately with a FeatureNotSupportedException.
  • Another might fall back to the old behavior and succeed.

  If we only deduped by TopicName, a caller that expects a failure could incorrectly receive a successful result from the other caller. This breaks the method contract for that caller.

• Even when the broker supports PIP-344, the metadataAutoCreationEnabled flag changes the request sent. Coalescing requests with different values for this flag hides the caller’s chosen behavior and side effects (like topic auto-creation).

Regarding your point about increasing request volume: this change still correctly deduplicates all concurrent calls that use the exact same parameters. A new request is only sent when the parameters are different, ensuring we respect the caller's intent while still preventing redundant traffic for identical calls.

Why could take the method params into account ? There will be more request to the broker, but the result is the same.

@Technoboy- I think that this is more about correctness than the possibility that the broker response might be the same in most cases. It's strictly not the same in all cases. Therefore I think that such bugs should be fixed.

This is not a bug

@Technoboy- I think that depends on how you define a bug. The impact of the issue is that boolean metadataAutoCreationEnabled, boolean useFallbackForNonPIP344Brokers parameters for the getPartitionedTopicMetadata method are ignored for any other requests which are made while there's a request in progress. Let's say that the first request is made with metadataAutoCreationEnabled=false and while it's in progress a request with metadataAutoCreationEnabled=true is made. This will definitely result in an inconsistent situation. However, I agree that the likelihood that this would happen is low. Regardless of that, such issues should be fixed and I would consider them bugs. Your definition of a bug could vary and I think it's fine.

Make sense

Codecov Report

❌ Patch coverage is 61.11111% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.30%. Comparing base (0896c0a) to head (ae68bbd).
⚠️ Report is 2 commits behind head on master.

@@             Coverage Diff              @@
##             master   #24965      +/-   ##
============================================
- Coverage     74.44%   74.30%   -0.14%     
+ Complexity    34071    33520     -551     
============================================
  Files          1920     1920              
  Lines        150062   150077      +15     
  Branches      17404    17408       +4     
============================================
- Hits         111708   111515     -193     
- Misses        29495    29672     +177     
- Partials       8859     8890      +31