fix(bot): log handler and middleware failures instead of printing them - #40
Merged
Merged
Conversation
A failed pinned-message delete and a failed metrics write both reported
themselves with print(), so in the container they landed on stdout untagged
instead of in the loguru sink the rest of the bot uses. Both now log a warning
with {e!r} so the exception type survives.
cli.py keeps its prints (click entry point, that's user output) but no longer
drops the alembic error text it caught.
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Two failure paths reported themselves with
print(), so in the container theywent to stdout untagged instead of into the loguru sink everything else uses —
no level, no timestamp, invisible to log collection.
bot_handler.delete_pinned_service_message: a failed delete is expectedwhenever the bot lacks rights, so it's a warning rather than nothing.
MetricsMiddleware._save_metrics: losing the metrics file write is worthseeing too.
Both log with
{e!r}so the exception type survives.cli.pykeeps itsprint()calls — it's a click entry point and those are useroutput — but the alembic handler was discarding the error text it had just
caught, so it now prints the message next to the label.