Pika confirm_delivery not accepting callback argument

[margaretli27]

Based on the method signature of confirm_delivery, I expect to be able to set two different callback parameters. However when I try that with pika 1.3.1 (or 1.3.0), with channel.confirm_delivery(on_delivery_confirmation) where on_delivery_confirmation is my callback, I get

TypeError: confirm_delivery() takes 1 positional argument but 2 were given

I inspected the method signature directly in my terminal and saw the two parameters I expect were absent.

>>> inspect.getfullargspec(channel.confirm_delivery)
FullArgSpec(args=['self'], varargs=None, varkw=None, defaults=None, kwonlyargs=[], kwonlydefaults=None, annotations={})

But in the source code they are clearly there. Am I missing something really obvious with using this method, or did the parameters get sneakily removed at some point? Appreciate any guidance here

[lukebakken]

Hello! Please share all of your code. Ideally, I should be able to clone a git repository and run it.

The reason I ask is that by having your code I don't have to guess.

[lukebakken]

OK, I see what's going on. Since you're using BlockingConnection, Pika takes care of the confirmations behind the scenes (https://github.com/lukebakken/pika-1415).

If you have low message publishing rates, this is fine. Otherwise, you should use SelectConnection and handle confirmations asynchronously:

https://github.com/pika/pika/blob/main/examples/confirmation.py

Let me know if you have any other questions!

[margaretli27]

I see, thanks! Does the delivery tag in the frame increment in perpetuity? I would like publish a batch of messages and infer from that tag which messages can be acked/nacked. I see this example of how to ack/nack multiple messages, where the publisher tracks an incrementing number; this seems to assume that the publisher's counter for a given message will always match the delivery tag of that message's ack. I.e. if a message is published with counter 10, any ack with delivery tag ≥ 10 must mean this message is confirmed.

[lukebakken]

if a message is published with counter 10, any ack with delivery tag ≥ 10 must mean this message is confirmed

Yes that's how it works. You must ack with a tag that has actually been delivered, of course.

[margaretli27]

Right. If I understand correctly though, the publisher cannot set the delivery tag (the broker does that). So in the linked example, the publisher increments the message counter but it is not guaranteed that the delivery tag of the message being published exactly matches the current message counter, if e.g. for some reason the publisher restarts and has message counter back at 0. Did I miss anything with that reasoning?

[lukebakken]

the publisher cannot set the delivery tag (the broker does that)

Are you certain that RabbitMQ sets delivery tags? Check out the rabbit_channel.erl source code.