feat(GAL): Trigger derived data rebuild after project backfill completes#119783
Conversation
When the project-level GAL backfill finishes (no more activities to process), fire process_project_derived_data to rebuild GroupDerivedData for all groups that are missing it. This ensures derived data is up-to-date after a backfill, especially after a reset that deletes all GroupDerivedData rows. Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 7d45815. Configure here.
The derived data rebuild only fired when the batch query returned empty. A final partial batch (len < batch_size) would skip both the self-chain and the rebuild. Add the trigger to the else branch so backfills that don't end on an exact batch boundary still rebuild. Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
| ) | ||
| activities = list(qs.order_by("datetime", "id")[:batch_size]) | ||
|
|
||
| from sentry.issues.derived.tasks import process_project_derived_data |
|
|
||
| from sentry.issues.derived.tasks import process_project_derived_data | ||
|
|
||
| if not activities: |
There was a problem hiding this comment.
I wish we could say "if we didn't backfill, no generation should be necessary" but we're not that organized yet.
There was a problem hiding this comment.
we can actually detect when were on the first batch, because we would have no cursor... ill add a check to cover this case
There was a problem hiding this comment.
no, currently we don't have a "backfill unnecessary so gdd works without it" state, so backfill functions as our enable step, even though conceptually we should only need regen if we change history.
There was a problem hiding this comment.
hmm this would only cover an empty project though, would ahve to thread like the converted count, to remember if we ever converted anything, not sure its worth the additional complexity
There was a problem hiding this comment.
no sure I follow exactly, just to be sure we are on the same page - the reprocess I trigger here doesnt redo the GDD, but the reset task deletes it when it starts, so the reset task will cause it all to get created.
Anyway not sure its related to the comment, bottom line - I think I prefer possibly triggering this needlessly than to add some more logic just to remember if we converted an activity somewhere along the chain. And the GDD regeneration only fills in gaps so I think were good
Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>

Summary
process_project_derived_datato rebuildGroupDerivedDatafor all groups missing itGroupDerivedDatarowsprocess_project_derived_dataonly processes groups without an existingGroupDerivedDatarow, so it's safe to call unconditionallyTest plan
test_triggers_derived_data_on_completionverifies the task is called on backfill completion