Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nacks are treated as exceptions / failures in the subscriber #837

Open
mbrancato opened this issue Dec 5, 2024 · 0 comments
Open

Nacks are treated as exceptions / failures in the subscriber #837

mbrancato opened this issue Dec 5, 2024 · 0 comments

Comments

@mbrancato
Copy link

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.

Related to #516

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant