Open romainb-met opened 1 year ago
I'm having a similar problem. I'm using JetStream as a broker for a distributed task manager (taskiq), and when the NATS connection is interrupted, the workers simply stop fetching messages without raising an exception that could be caught. I see the UnexpectedEOF error in Sentry and have to manually restart the workers.
It seems to be a bug in the nats-py library.
What version were you using?
nats-py==2.2.0 nats-server: nats:2.9.14-alpine (running in a k8s pod) CLI : v0.0.35 Python 3.8
What environment was the server running in?
Kubernetes pod.
Is this defect reproducible?
Given one has a NATS server available and can connect to it yes by using the following script :
Given the capability you are leveraging, describe your expectation?
In case the connection of the server is lost during fetch (
nats.errors.UnexpectedEOF)
I would like for the error to be properly raised so that I can catch it with an Except.Given the expectation, what is the defect you are observing?
Here my attempt was to catch the
UnexpectedEOF
generated when I cut the port forward to the server. TheUnexpectedEOF
is indeed created, but not raised properly. It should be handled perhandle_nats_error
and then catch per theexcept
. But here it seems that default error callback is called first somehow. See logs below :My expectation is no traceback and no
TimeoutError
instead ofUnexpectedEOF
:Any ideas on how to reach this behavior ? Or if maybe newer version of the client may fix this ?