-
Notifications
You must be signed in to change notification settings - Fork 54
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
feat: Added flushes/close functionality to logging handlers #917
base: experimental-v4
Are you sure you want to change the base?
Conversation
if self.transport is None: | ||
self.transport = self._transport_cls( | ||
self.client, self.name, resource=self.resource | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this mean the handler has been closed? Why not just raise an error, instead of re-creating the transport?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I based this off of some logging handlers I saw in the Python standard library, which will reopen a closed connection if that connection is closed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I think this adds extra complexity, so I'd prefer to keep them permanently closed if we can get away with that
But if you think this behavior would help us integrate with the standard library, it makes sense to keep it.
def close(self): | ||
"""Closes the log handler and cleans up all Transport objects used.""" | ||
self.transport.close() | ||
self.transport = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the idea of using transport == None
as a way to check if the handler is closed. That makes the types quite a bit more complicated.
Can't we use a new flag for this?
_CLOSE_THREAD_SHUTDOWN_ERROR_MSG = ( | ||
"CloudLoggingHandler shutting down, cannot send logs entries to Cloud Logging due to " | ||
"inconsistent threading behavior at shutdown. To avoid this issue, flush the logging handler " | ||
"manually or switch to StructuredLogHandler." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe mention client.close or handler.close too?
"""Callback that attempts to send pending logs before termination.""" | ||
if not self.is_alive: | ||
return | ||
|
||
# Print different messages to the user depending on whether or not the | ||
# program is shutting down. This is because this function now handles both | ||
# the atexit handler and the regular close. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we decouple this? Maybe let the caller pass in a message or something?
For design doc see go/python-logging-background-thread
Fixes #<issue_number_goes_here> 🦕