[Bug] Return flow-control permit when client seek by messageID

[programmerahul]

Search before reporting

• I searched in the issues and found nothing similar.

Read release policy

• I understand that unsupported versions don't get bug fixes. I will attempt to reproduce the issue on a supported version of Pulsar client and Pulsar broker.

User environment

broker and client version 4

Issue Description

When a consumer seeks to (or is created with) a specific startMessageId, the broker re-dispatches the boundary message, which the client filters out in messageReceived() via the isSameEntry(msgId) && isPriorEntryIndex(...) block. That block released the payload and returned without calling increaseAvailablePermits(), so the dropped message's outstanding flow-control permit was never repaid (it is not delivered, so messageProcessed() never runs for it).

Each seek-to-messageId therefore leaks one permit. It is masked at normal receiver queue sizes (seek re-establishes flow control), but with receiverQueueSize=1 the single leaked permit exhausts the whole budget and the consumer stalls immediately after the seek -- the message after the seek target is never delivered. Not chunking-specific; applies to plain messages too.

Error messages

There is one permit leak when client uses seek by message id in their client code

Reproducing the issue

Using consumer.seek(msgId) in consumer code. and set .receiverQueueSize(1). With that the consumer will freeze

Additional information

No response

Are you willing to submit a PR?

• I'm willing to submit a PR!