Closed roshanr10 closed 1 month ago
Hi @roshanr10 , Thank you very much for the PR! Could you please add a test for this case?
Hi @roman-right , thanks for the update, following up on this – can you please provide more insight into why DuplicateKeyError is being caught? As far as I've experienced, there is no unique ID index on the revision id, so it would never be caught in normal usage.
this is what I've done to get information from the underlying DuplicateKeyError but not sure why it's intercepted
except beanie.exceptions.RevisionIdWasChanged as e:
if e.__context__.details["keyPattern"]["<YOUR_KEY_PATTERN"] == 1:
# HANDLE
This PR is stale because it has been open 45 days with no activity.
This PR was closed because it has been stalled for 14 days with no activity.
Currently a few exceptions are lost due to the way Beanie handles the try/except & raise approach – using exception chaining / re-raising the same exception ensures the appropriate values can be used for debugging downstream.
Especially with
DuplicateKeyError
, it's incredibly unclear to the user when they get aRevisionIdWasChanged
instead with no way to trace it back to aDuplicateKeyError
.