Bug
The gRPC ACK path removes the proxy-managed receipt-handle mapping before the Broker ACK completes. If the ACK call then fails exceptionally (transport/runtime failure), the mapping is never restored.
This matters when Proxy auto-renew has already replaced the client-visible receipt handle with a newer one. A retry from the client normally resolves its original handle through MessageReceiptHandle; after the failed ACK removed that mapping, the retry can fall back to the stale client handle instead.
Current flow
AckMessageActivity.getHandleString calls messagingProcessor.removeReceiptHandle(...) first. The returned MessageReceiptHandle supplies the latest renewed handle, but only the string is retained. processAckMessage then calls ackMessage(...) and converts an exceptional future into an error response without re-registering the removed mapping.
The batch ACK path has the same ordering: it removes all managed handles while constructing ReceiptHandleMessages before batchAckMessage(...) completes.
Reproduction
On develop@bc33e8e4d7b25089af5f51bc669bdfedabfebe7d, a regression test registers a newer managed handle, makes removeReceiptHandle return it, and makes ackMessage return an already exceptionally-completed future.
The request correctly returns an internal error, but verification fails because addReceiptHandle(...) is never invoked. The preceding 11 modules in the proxy -am reactor all succeed; only this regression fails.
Expected behavior
Treat exceptional completion as an indeterminate/transient ACK attempt: restore any managed receipt-handle entry removed for that attempt so a client retry can still resolve to the latest handle.
- Normal ACK success keeps the current remove-on-ACK behavior.
- Explicit Broker/business ACK results keep their current semantics.
- Synchronous failures after removal should restore the mapping as well.
- Batch ACK should restore the removed mappings only when the whole batch invocation fails exceptionally/synchronously, not for ordinary per-entry business results.
No wire format or Broker ACK protocol change is needed.
Bug
The gRPC ACK path removes the proxy-managed receipt-handle mapping before the Broker ACK completes. If the ACK call then fails exceptionally (transport/runtime failure), the mapping is never restored.
This matters when Proxy auto-renew has already replaced the client-visible receipt handle with a newer one. A retry from the client normally resolves its original handle through
MessageReceiptHandle; after the failed ACK removed that mapping, the retry can fall back to the stale client handle instead.Current flow
AckMessageActivity.getHandleStringcallsmessagingProcessor.removeReceiptHandle(...)first. The returnedMessageReceiptHandlesupplies the latest renewed handle, but only the string is retained.processAckMessagethen callsackMessage(...)and converts an exceptional future into an error response without re-registering the removed mapping.The batch ACK path has the same ordering: it removes all managed handles while constructing
ReceiptHandleMessages beforebatchAckMessage(...)completes.Reproduction
On
develop@bc33e8e4d7b25089af5f51bc669bdfedabfebe7d, a regression test registers a newer managed handle, makesremoveReceiptHandlereturn it, and makesackMessagereturn an already exceptionally-completed future.The request correctly returns an internal error, but verification fails because
addReceiptHandle(...)is never invoked. The preceding 11 modules in theproxy -amreactor all succeed; only this regression fails.Expected behavior
Treat exceptional completion as an indeterminate/transient ACK attempt: restore any managed receipt-handle entry removed for that attempt so a client retry can still resolve to the latest handle.
No wire format or Broker ACK protocol change is needed.