ref(quick-start): Replace 'record' with 'create_or_update' in 'record_new_project' #86663
Conversation
github-actions
bot
added
the
Scope: Backend
| ) | ||
| if not success: | ||
| # if we updated the task "first project", it means that it already exists and now we want to create the task "second platform" | ||
| if not created: | ||
| # Check if the "first project" task already exists and log an error if needed | ||
| first_project_task_exists = OrganizationOnboardingTask.objects.filter( |
There was a problem hiding this comment.
I think that it is now guaranteed that the first project task exists, as create_or_update is definitely called.
| @@ -98,14 +98,17 @@ def record_new_project(project, user=None, user_id=None, origin=None, **kwargs): | |||
| ), | |||
| ) | |||
|
|
|||
| success = OrganizationOnboardingTask.objects.record( | |||
| _, created = OrganizationOnboardingTask.objects.create_or_update( | |||
There was a problem hiding this comment.
Since this signal is sent only on project creation, we don't need to do create_or_update, we can just do create and save ourselves multiple db calls which would be executed in create_or_update
There was a problem hiding this comment.
so we just do the try catch and if it fails, we record the second platform? if it fails I would like to still check if the project was recorded before saving the second platform, because it can fail for other reasons too and not only integrity right?
There was a problem hiding this comment.
Ohh true true, my mistake...
So the overall flow needs to be:
- we either try to create or update, or we try to create and catch integrity error
- if it is not created or the error is caught- we try to create or update second platform object
There was a problem hiding this comment.
So to sum it up, your logic is good as it is, sorry Pri :/
There was a problem hiding this comment.
no problem 🙂 in this case, mind approving the PR? 🙏
| @@ -117,12 +120,14 @@ def record_new_project(project, user=None, user_id=None, origin=None, **kwargs): | |||
| level="warning", | |||
| ) | |||
|
|
|||
| OrganizationOnboardingTask.objects.record( | |||
| OrganizationOnboardingTask.objects.create_or_update( | |||
There was a problem hiding this comment.
Why is this called here, is it still needed?
My mistake, this needs to be called here
There was a problem hiding this comment.
we do not need to look for a cache here, do we?
There was a problem hiding this comment.
Nope, this won't be called that often
priscilawebdev
deleted the
priscila/ref/quick-start/replace-record-in-record_new_project-with-create_or_update
branch
* master: (57 commits) ref(getting-started): Change code to always update loader script when products changes (#86583) ref(spans): Detect performance issues directly in segments consumer (#86595) ref(getting-started): Update copies, replacing 'Sentry dashboard' with 'Sentry Issues' (#86672) ref(product-selection): Update code to not strip url (#86582) ref(quick-start): Replace 'record' with 'create_or_update' in 'record_new_project' (#86663) ref(assemble): Remove old `find_missing_chunks` method (#86588) fix(views):Exclude newly added views from last visited update as well (#86653) feat(workflow_engine): Only execute enabled Detectors (#86652) fix(autofix): Github links, remove seer branding, and UI cleanup (#86640) fix(seer-issues-patch) More parsing of functions for Python (#86558) ref(ui): Remove sentry.eot (#86649) feat(alerts): Restrict uptime/crons overview buttons for alerts:write (#86436) chore(deps): bump axios from 1.7.7 to 1.8.2 (#86642) deps(ui): Upgrade prettier (#86634) deps(ui): Upgrade eslint, biome (#86630) fix(shared-views): Fix default view passing to last visited endpoint (#86632) feat(billing): update copy for payg disabled CTA (#86143) ref(ui): Remove usage of withOrganization from organizationAuthList (#86554) fix(crons): Fix disabled state of disable button (#86637) feat(ui): Replace OrganizationAuth DeprecatedAsyncComponent (#86556) ...
Problem
Users occasionally experience an issue where the onboarding task for the "first project" is not recorded, even if one or more projects have been created. Our hypothesis is that a rollback is triggered during the process, and due to the 1-hour cache, the onboarding task isn't recorded when users attempt to create a project again. You can read more here.
Solution
We plan to spend some time refactoring the onboarding receivers to fix this properly as the issue maybe be happening for other receivers too. But for now, this PR updates the
record_new_projectfunction to usecreate_or_updateinstead ofrecord. This removes the need for a cache when handling the "first project" and "second platform" onboarding tasks. Since this function doesn't run often - unlikerecord_release_received, which uses theevent_processsignal - it's fine to skip the cache here