Is Sneakers' retry handler approach thread safe?

[dccunha]

Hey guys!

First of all, thanks for reviving this project. I guess the whole community of Sneakers users appreciates that 🤗

Now to the question 🤓

An in-queue retry handler signature receives a channel, queue, and a couple of options, as the MaxRetry class demonstrates:

https://github.com/jondot/sneakers/blob/master/lib/sneakers/handlers/maxretry.rb#L36

Inside Queue#subscribe the gem sends an instance variable with the channel to the handler initializer:

https://github.com/jondot/sneakers/blob/master/lib/sneakers/queue.rb#L56

This same handler instance is passed over until we start to create tasks inside a pool of threads:

https://github.com/jondot/sneakers/blob/master/lib/sneakers/worker.rb#L50-L52

I've found a couple of issues on Bunny's repo stating we shouldn't be doing that:

ruby-amqp/bunny#386 (comment)

Is my conclusion correct that Sneakers share the same channel connection among the threads?

[michaelklishin]

Consuming that way is safe unless N threads use the same consumer tag, which they likely don't in the case of Kicks.

Acknowledging a single delivery from N threads can be safe in practice, acknowledging "up to N" deliveries (multiple deliveries at a time) is a no-no.

Publishing from N threads is a no-no.