-
Notifications
You must be signed in to change notification settings - Fork 1
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
Log errors during faculty processing #659
Conversation
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.
Looks good
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.
👍
main/models.py
Outdated
except: | ||
# Just ignore any errors... | ||
except Exception as e: | ||
logger.error(f"Error processing faculty for user: {e}", exc_info=True) |
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 kind of half-remember it being best practice to not format log strings actively, but to use the formatting provided by logger.error()
itself. Like that the logging handlers and formatters can work their magic.
But I can't find a reference to that anywhere so it might not even be the case anymore. Not a blocking issue either way.
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.
Just to add my 5 cents here (I don't know why I'm getting email notifications from this PR): Pylint was mad at me last week for using f-strings instead of the old format: https://stackoverflow.com/questions/34619790/pylint-message-logging-format-interpolation. Maybe you are thinking about that?
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.
Yeah y'all are right that this isn't the ideal/correct way to do this. (One point not even mentioned is me formatting an exception into a string, which is definitely the worse offense here actually).
The method I used (f-strings) was me being lazy. The reason (doing it at all) was because I wasn't sure if Sentry would correctly capture the whole exception context. (That's what exc_info
does btw).
I just did a local test, and it does! As this makes the string-format unnecessary, I removed it
Note: this targets acceptation to hasten deployment
I took a look at how prevalent #611 is... it's bad. Over 85% of new users this year do not have a faculty attached.
Before I start accusing ITS, I want to see if we're at fault. So, this PR adds a log call to the except we've been ignoring. This should show up in Sentry.