Support acks_late configuration about rusty-celery HOT 5 CLOSED

Alright, thanks for the info, I'll give it a try!

from rusty-celery.

Good catch. I am leaning towards option 2 because that seems much simpler. And I think it's perfectly reasonable to treat retrying and acking as separate actions as far as the broker is concerned.

from rusty-celery.

Hi @epwalsh, I'd like to work at this issue if you can give some pointers on how to get started. Thanks!

from rusty-celery.

Hey @crash-g! Awesome, that would be much appreciated!

So, as rough guide, we need

• a new method on the CeleryBuilder struct - something like pub fn acks_late(mut self, late: bool) -> Self {...} - and a corresponding field in the Celery struct.
• Then within Celery::try_handle_delivery we need to modify the behavior if acks_late is false. In particular, if acks_late=false, we need to call self.broker.ack(delivery).await?; right before tracer.trace().await.

There might be some other details I am missing but let me know if you have any questions!

from rusty-celery.

It looks like a little care is needed to prevent acking a message twice.

The problem is that after processing the message, we call self.broker.retry in case of a recoverable error, and currently amqp broker acks the message when retrying. I see a couple of possible solutions, but feel free to suggest something else entirely:

1. Modify the ack implementation for amqp to only send the ack once (basically, by keeping track of already acknowledged messages)
2. Modify the retry implementation for amqp not to send the ack

Of course, I'm assuming that acking twice is an issue: if it is not, then the above considerations do not apply.

from rusty-celery.