Downgrade some expected "already exists" errors to info-level logging (#958)#1075
Conversation
MelissaAutumn
left a comment
MelissaAutumn
left a comment
There was a problem hiding this comment.
Good start, I'd like to see those private functions dropped and code moved inside our existing classes where it makes sense.
| POSTGRES_DUPLICATE_KEY_MARKER = 'duplicate key value violates unique constraint' | ||
|
|
||
|
|
||
| def is_already_exists_error( |
There was a problem hiding this comment.
This can live inside the KeycloakError class. No need for it to live in outside.
There was a problem hiding this comment.
The is_already_exists_error was put in the global scope with the understanding that the pattern of generating exceptions from double-click-to-insert affects all things we insert-- the exception we noticed related to keycloak happens to be the first one. As we scale, the pattern will repeat for everything we insert, see note below.
But in the spirit of YAGNI, I've moved it into the narrowest scope where it's actually used now, the ImportUserError class. Later when we hit similar cases and refactor to handle those, we can refactor to move this back to a shared location.
| return True | ||
|
|
||
| error_text = ' '.join(filter(None, [error_code, error_desc, error])).lower() | ||
| return POSTGRES_DUPLICATE_KEY_MARKER in error_text |
There was a problem hiding this comment.
Is this something we hit? I don't remember duplicate key errors here, but also I wasn't really looking at the response other than status code.
There was a problem hiding this comment.
That addition was experience-based rather than evidence-based. Having managed busy Postgres-backed websites in the past, at scale that became a common pattern: The user's double-click behavior would lead to a race condition to insert twice. One insert would win and the other would throw the "duplicate key" error.
We could remove it because we haven't hit it yet, but based on the scale we are trying to build we likely will. Also, it seems is the best solution: there's not a reasonable way to prevent the condition from happening: the best path seems to be accept that we'll trigger the duplicate key violation periodically, then explicitly accept this condition as OK in cases were we expect them to be safe, like a double-click for inserting record targeted here.
|
Feedback has been addressed in a fixup commit that can be reviewed and then squashed during merging. |
MelissaAutumn
left a comment
MelissaAutumn
left a comment
There was a problem hiding this comment.
I believe we have a linting error now 😄
And a suggestion to be slightly more narrow in the exception usage. Otherwise good stuff.
…#958) For web/db apps, a common source of exceptions stem from users double-clicking some button or link to add a thing when it only needs a single click. In these cases, the first request will trigger a successful addition and the second one will trigger some kind of "already exists" condition, which is harmless to ignore. For some known cases like that, we downgrade them from throwing exceptions to info-level logging. Other cases of adding things where we still would not expect exceptions to be triggered reamin as exceptions.
- Re-organize code - Remove necessary logging
markstos
force-pushed
the
issue-958-dont-log-to-sentry
branch
from
6ecd2d1 to
1e450ed
Compare
|
Thanks! |
2 participants
For web/db apps, a common source of exceptions stem from users double-clicking
some button or link to add a thing when it only needs a single click.
In these cases, the first request will trigger a successful addition and the second
one will trigger some kind of "already exists" condition, which is harmless to ignore.
For some known cases like that, we downgrade them from throwing exceptions to
info-level logging.
Other cases of adding things where we still would not expect exceptions to be
triggered reamin as exceptions.
Applicable Issues
QA Log
Sentry.