logging: Make logging.info log to Sentry
#5720
Closed
Conversation
This file contains 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
We have a log line NotifTroubleshootingScreen: MailComposer reports a sent email. that I'd *thought* was getting sent to Sentry, but apparently not. The line is meant to help us detect potential cases where the user thought they'd contacted support through the app, but we don't see an email on our side. We're not aware of such cases yet, but in principle it could happen. Since it seems helpful to have a function for logging to Sentry at an "info" level, rewrite `logging.info` based on `logging.warn` and `logging.error` so it does that. That should cause that notif-troubleshooting line to go to Sentry. The one other callsite of `logging.info` is redundant with a breadcrumb added with the same information; remove it and an unexplained test assertion about it.
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this pull request
Oct 5, 2023
…entry An alternative approach to zulip#5720, to help us detect potential cases where the user thought they'd contacted support through the app, but we don't see an email on our side. (We're not aware of such cases yet, but in principle it could happen.) It seems probably fine to do it at the "warn" level rather than "info". If someone sends one of these emails, it usually means something's not quite right with notifications somewhere, making "warn" probably at least as appropriate as "info" in more cases than not.
gnprice
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this pull request
Oct 5, 2023
…entry An alternative approach to zulip#5720, to help us detect potential cases where the user thought they'd contacted support through the app, but we don't see an email on our side. (We're not aware of such cases yet, but in principle it could happen.) It seems probably fine to do it at the "warn" level rather than "info". If someone sends one of these emails, it usually means something's not quite right with notifications somewhere, making "warn" probably at least as appropriate as "info" in more cases than not.
|
Closing as superseded by #5775. |
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.
We have a log line
NotifTroubleshootingScreen: MailComposer reports a sent email.
that I'd thought was getting sent to Sentry, but apparently not. The line is meant to help us detect potential cases where the user thought they'd contacted support through the app, but we don't see an email on our side. We're not aware of such cases yet, but in principle it could happen.
Since it seems helpful to have a function for logging to Sentry at an "info" level, rewrite
logging.infobased onlogging.warnandlogging.errorso it does that. That should cause that notif-troubleshooting line to go to Sentry.The one other callsite of
logging.infois redundant with a breadcrumb added with the same information; remove it and an unexplained test assertion about it.