You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the pubsub subscribe() function, there is no clean way to negatively acknowledge a message. The only way to do it inside the subscriber is to either run your own nacker() process, or to raise an exception, which will go to the default nacker(). The problem is that the library treats exceptions as failures, even though when processing a message, there are a number of possible reasons to nack a message due to transient / retryable conditions.
except Exception as e:
if nack_queue:
await nack_queue.put(message.ack_id)
log.exception('application callback raised an exception: %s', e)
metrics_client.increment('pubsub.consumer.failed')
metrics.CONSUME.labels(outcome='failed').inc()
It seems like it might be good to have either specific exception types, or the ability to configure how the exceptions are handled. Explicit ack() and nack() methods would be great on the SubscriberMessage class when used with subscribe(). That would decouple acking / nacking from potential exceptions, which could then all be treated as errors.
Right now I'm raising an exception on failures (for various reasons), but that then creates excessive exception logging that I don't need / want.
In the pubsub
subscribe()
function, there is no clean way to negatively acknowledge a message. The only way to do it inside the subscriber is to either run your ownnacker()
process, or to raise an exception, which will go to the defaultnacker()
. The problem is that the library treats exceptions as failures, even though when processing a message, there are a number of possible reasons to nack a message due to transient / retryable conditions.It seems like it might be good to have either specific exception types, or the ability to configure how the exceptions are handled. Explicit
ack()
andnack()
methods would be great on theSubscriberMessage
class when used withsubscribe()
. That would decouple acking / nacking from potential exceptions, which could then all be treated as errors.Right now I'm raising an exception on failures (for various reasons), but that then creates excessive exception logging that I don't need / want.
Related to #516
The text was updated successfully, but these errors were encountered: