-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
PubSub: AttributeError: 'NoneType' object has no attribute 'received_messages' #9975
Comments
While this won't replicate every time for me I can get it to trigger this exception every 5th or so run. It's odd to manually close the underlying channel, but might be useful to track the issue down. Of note when this occurs for me in normal code i'm not manually closing the channel.
Running with the same configuration as the initial report. |
I was able to reproduce the issue by running a subscriber that pulls the messages using a streaming pull, and then cancelling the future with a keyboard interrupt. In fact, the reproduction rate is 100% on my machine with my own test script. future = subscriber.subscribe(subscription_name, callback)
try:
future.result()
except KeyboardInterrupt:
future.cancel() Log output:
It appears that upon cancelling, the internal "on message receive" callback is passed a google-cloud-python/pubsub/google/cloud/pubsub_v1/subscriber/_protocol/streaming_pull_manager.py Lines 533 to 547 in 52b54aa
Should be straightforward to add logic to handle this case. @anguillanneuf I can fix this pretty soon, just please let me know if you have already started working on this to not duplicate the work, thanks! Update: Actually found some extra time even today, and fixed it myself. Opened #9982. |
Environment details
OS: OS X and Linux
Python 3.8.1rc1
google-cloud-pubsub==1.1.0
PubSub Emulator running out of the
google/cloud-sdk:latest
docker imageSteps to reproduce
I'm working on getting an isolated reproduction of this, but at current it's "run my integration tests against the PubSub emulator" (closed source, unfortunately) and see that on 1.1.0 the stack trace listed below gets written to stdout/stderr as it's seemingly occurring in another thread (not in my logs), and the test suite continues on normally and eventually passes. When pinned on 1.0.2, the stack trace below does not occur.
For whatever it's worth, our code using PubSub via a streaming pull future has not changed recently.
I get that this isn't very helpful by itself but I wanted to get report this sooner than later, instead of just pinning to 1.0.2 and forgetting about it.
Stack trace
The text was updated successfully, but these errors were encountered: