Retry Publish Option about go-rabbitmq HOT 5 CLOSED

I did a quick test and indeed these type of errors ¹² are not propagated from the amqp base library; there is nothing any wrapping library can do for you (well, short of checking things, which you could also do in app layer beforehand ³).

The fairly clean way out ⁴ is to call PublishWithDeferredConfirmWithContext() and then wait on the returned PublisherConfirmation (array of type amqp.DeferredConfirmation) via various tests (array length, [0] is valid then amqp calls on [0] with context and/or timers, whatever the amqp library offers, ref. amqp.DeferredConfirmation See also the publisher_confirm example.

I hope this helped a bit.

from go-rabbitmq.

The Publish function does return an error, is there something else I'm missing?

from go-rabbitmq.

Hi, thanks for the feedback!

Yes, the Publish function does return an error in its signature.
However, when Publish fails, the error is not propagated to the caller.

For example, in the scenario if the Publish triggers an ACCESS_REFUSED error.
The error return value is nil.

Then, the logger logs:

channelmanager/channel_manager.go:69: attempting to reconnect to amqp server after close with error: Exception (403) Reason: "ACCESS_REFUSED - write access to exchange '...' in vhost '...' refused for user '...'" 
channelmanager/channel_manager.go:101: waiting 5s seconds to attempt to reconnect to amqp server
channelmanager/channel_manager.go:124: error closing channel while reconnecting: Exception (504) Reason: "channel/connection is not open"
channelmanager/channel_manager.go:71: successfully reconnected to amqp server
publish.go:115: successful publisher recovery from: Exception (403) Reason: "ACCESS_REFUSED - write access to exchange '...' in vhost '...' refused for user '...'" 

This test has been run with github.com/wagslane/[email protected]

When the error is ACCESS_REFUSED, that seems legit to discard the error.
However, I'm trying to implement a retry mechanism when the rabbitmq server is being upgraded / restarted by a cloud provider (e.g. AWS AmazonMQ RabbitMQ).

Thanks!

from go-rabbitmq.

Thanks for investigating into this @LucaWolf !

I'm quite surprised that the underlying library does not propagate 540 exceptions.
I tried to look into the library which exceptions returns an error but could not find it.

I'll use PublishWithDeferredConfirmWithContext to handle this case, thanks!

from go-rabbitmq.

Glad you found that!

from go-rabbitmq.