This repository was archived by the owner on Mar 9, 2026. It is now read-only.
feat: add context manager capability to subscriber - #32
Merged
Conversation
tseaver
self-requested a review
February 18, 2020 18:16
tseaver
reviewed
Feb 18, 2020
tseaver
approved these changes
Feb 20, 2020
Contributor
|
I just had a chance to take a look at this. It looks good, thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4.
This PR gives users a more handy way of closing the subscriber's underlying channel.
How to test
DeadlineExceededresponse.withblock.Actual result (before the fix):
Subscriber client cannot be used as a context manager. Using it without the context results in open sockets being leaked until the Python process terminates,
Expected result (after the fix):
Subscriber client releases the open sockes after exiting the context management block.
Things to consider/discuss
_closeflag to the client and additional logic that would raise an error if any of its methods are used after the client has been closed. Since a lot of the methods are copied from the generatedSubscriberClientGAPIC class, that extra logic would bloat the code without that much of a gain (the GRPC channel itself already raises an informative "channel closed" error).__del__()method that would callclose()automatically, as this could bring its own set of potential problems.PR checklist: