-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Defer most signal handling code until after the end of the current transaction #7460
Merged
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
/check |
❌ Some checks failed |
SpecLad
force-pushed
the
handle-after-transaction
branch
2 times, most recently
from
February 9, 2024 11:07
e7124f7
to
1c3b2ad
Compare
/check |
❌ Some checks failed |
…ansaction Non-database actions like deleting directories, sending webhooks, scheduling reports should only be done after the current transaction is committed. If we do it immediately, and the transaction is later aborted, then we will have (for example) sent a webhook about an event that didn't actually happen. There's also a secondary benefit to moving this action outside of the transaction; the less time we spend inside a transaction, the better, since a transaction may lock out other clients from working on the affected DB rows. In addition, prevent the affected actions from crashing the view handler with an exception (using the `robust=True` option). I don't think it's reasonable to (for example) return a 500 response to a `PATCH` request just because we failed to send the corresponding webhook. There is one more type of action that should be modified in this way (sending events), but it would be easier to do that after a refactoring that I did in another patch, so I'll do it later.
SpecLad
force-pushed
the
handle-after-transaction
branch
from
February 9, 2024 15:44
1c3b2ad
to
636c4d8
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## develop #7460 +/- ##
===========================================
- Coverage 83.59% 83.56% -0.03%
===========================================
Files 374 374
Lines 39742 39755 +13
Branches 3731 3731
===========================================
Hits 33223 33223
- Misses 6519 6532 +13
|
Marishka17
reviewed
Feb 13, 2024
Marishka17
approved these changes
Feb 13, 2024
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.
LGTM
3 tasks
bsekachev
pushed a commit
that referenced
this pull request
Feb 13, 2024
…ansaction (#7460) Non-database actions like deleting directories, sending webhooks, scheduling reports should only be done after the current transaction is committed. If we do it immediately, and the transaction is later aborted, then we will have (for example) sent a webhook about an event that didn't actually happen. There's also a secondary benefit to moving this action outside of the transaction; the less time we spend inside a transaction, the better, since a transaction may lock out other clients from working on the affected DB rows. In addition, prevent the affected actions from crashing the view handler with an exception (using the `robust=True` option). I don't think it's reasonable to (for example) return a 500 response to a `PATCH` request just because we failed to send the corresponding webhook. There is one more type of action that should be modified in this way (sending events), but it would be easier to do that after a refactoring that I did in another patch, so I'll do it later.
SpecLad
added a commit
that referenced
this pull request
Feb 15, 2024
Merged
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.
Motivation and context
Non-database actions like deleting directories, sending webhooks, scheduling reports should only be done after the current transaction is committed. If we do it immediately, and the transaction is later aborted, then we will have (for example) sent a webhook about an event that didn't actually happen.
There's also a secondary benefit to moving this action outside of the transaction; the less time we spend inside a transaction, the better, since a transaction may lock out other clients from working on the affected DB rows.
In addition, prevent the affected actions from crashing the view handler with an exception (using the
robust=True
option). I don't think it's reasonable to (for example) return a 500 response to aPATCH
request just because we failed to send the corresponding webhook.There is one more type of action that should be modified in this way (sending events), but it would be easier to do that after a refactoring that I did in another patch, so I'll do it later.
How has this been tested?
Checklist
develop
branch[ ] I have updated the documentation accordingly[ ] I have added tests to cover my changes[ ] I have linked related issues (see GitHub docs)[ ] I have increased versions of npm packages if it is necessary(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)
License
Feel free to contact the maintainers if that's a concern.