fix(backup): Fix OrgAuthToken async race#58064
Merged
Merged
Conversation
deb1456 to
9af7800
Compare
e354943 to
f27245c
Compare
Codecov Report
@@ Coverage Diff @@
## azaslavsky/backup/fix_monolith_env_detect #58064 +/- ##
==========================================================================
Coverage 78.94% 78.95%
==========================================================================
Files 5130 5130
Lines 223030 223055 +25
Branches 37562 37565 +3
==========================================================================
+ Hits 176078 176114 +36
+ Misses 41304 41292 -12
- Partials 5648 5649 +1
|
c7a3d06 to
3af49e1
Compare
f27245c to
e27514b
Compare
A `SENTRY_USE_MONOLITH_DBS=0` is now equivalent to the environment variable being entirely absent, which seemed to be responsible for previously divergent behavior.
3af49e1 to
9809892
Compare
e27514b to
1fde149
Compare
OrgAuthToken and OrganizationMapping are both control silo models. When importing the former, we want to make sure there are no token collisions, and mint new tokens for the importing model if there are. When a minting a new token, we need the org slug, which we previously pulled from the corresponding entry in the OrganizationMapping table. However, this assumes that prior Organization import, which triggers a `post_save()` generation of the corresponding OrganizationMapping in the control silo, has already successfully completed when we get around to importing our OrgAuthToken (much later in the import process, see fixtures/backup/model_dependencies/sorted.json for more). This is likely, but not guaranteed, to be true. A naive solution to this would be to make an RPC call from inside of OrgAuthToken's `write_relocation_import` method, but this causes an RPC inside of a database transaction in the control silo, which is disallowed. Instead, we modify the `pk_map` which tracks JSON pks -> newly imported pks, and add an additional optional field onto it: `slug`, which (for fields that possess it) stores the unique slug associated with that model instance. When we pass this over to the control silo, we'll already have all of the information we need to mint the new OrgAuthToken, thereby eliminating the need to do RPC-based lookups. Closes #205
1fde149 to
027cecf
Compare
Base automatically changed from
azaslavsky/backup/fix_monolith_env_detect
to
master
October 13, 2023 18:00
GabeVillalobos
approved these changes
Oct 13, 2023
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
OrgAuthToken and OrganizationMapping are both control silo models. When importing the former, we want to make sure there are no token collisions, and mint new tokens for the importing model if there are. When a minting a new token, we need the org slug, which we previously pulled from the corresponding entry in the OrganizationMapping table. However, this assumes that prior Organization import, which triggers a
post_save()generation of the corresponding OrganizationMapping in the control silo, has already successfully completed when we get around to importing our OrgAuthToken (much later in the import process, see fixtures/backup/model_dependencies/sorted.json for more). This is likely, but not guaranteed, to be true.A naive solution to this would be to make an RPC call from inside of OrgAuthToken's
write_relocation_importmethod, but this causes an RPC inside of a database transaction in the control silo, which is disallowed. Instead, we modify thepk_mapwhich tracks JSON pks -> newly imported pks, and add an additional optional field onto it:slug, which (for fields that possess it) stores the unique slug associated with that model instance. When we pass this over to the control silo, we'll already have all of the information we need to mint the new OrgAuthToken, thereby eliminating the need to do RPC-based lookups.Closes #205