Adrian/adjust ownerid task params

[adrianviquez]

Adjust owner_id to ownerid to adhere to task params

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. In 2022 this entity acquired Codecov and as result Sentry is going to need some rights from me in order to utilize my contributions in this PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

---

Note

Aligns owner export tasks to a single ownerid parameter and tightens error/cleanup flows.

• Switches owner_id → ownerid in TaskService.export_owner_data, admin trigger, task kwargs/logging, and all worker task implementations (ExportOwnerTask, ExportOwnerSQLTask, ExportOwnerArchivesTask, ExportOwnerFinalizeTask, ExportOwnerCleanupTask)
• Adds export_owner_task_name to routing/plan resolution so queue selection uses ownerid
• Makes _mark_export_failed_by_id atomic (updates only when status is IN_PROGRESS)
• Cleanup task now skips if export already completed; consolidates failure marking and consistently deletes partial files using ownerid-derived paths
• Updates manifest and path builders to use ownerid consistently

^{Written by Cursor Bugbot for commit 8d94926. This will update automatically on new commits. Configure here.}

[sentry]

Codecov Report

❌ Patch coverage is 0% with 19 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.53%. Comparing base (47c789c) to head (8d94926).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
apps/worker/tasks/export_owner_data.py	0.00%	19 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #670      +/-   ##
==========================================
+ Coverage   92.51%   92.53%   +0.02%     
==========================================
  Files        1295     1295              
  Lines       47689    47678      -11     
  Branches     1592     1592              
==========================================
  Hits        44121    44121              
+ Misses       3259     3248      -11     
  Partials      309      309              

Flag	Coverage Δ
apiunit	96.36% <ø> (ø)
workerintegration	58.48% <0.00%> (+0.04%)	⬆️
workerunit	90.14% <0.00%> (+0.06%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codecov-notifications]

Codecov Report

❌ Patch coverage is 0% with 19 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
apps/worker/tasks/export_owner_data.py	0.00%	19 Missing ⚠️

📢 Thoughts on this report? Let us know!

[calvin-codecov]

out of my curioisity: why are we separating out the export_owner_cleanup task to be separate after each of these other tasks vs before?

[adrianviquez]

Basically the cleanup is a callback task that we'll use if any task fails, so if you have some files linger in memory or smth, the cleanup task will empty and clean up the container. I guess the idea is only to run it when it needs to be ran you know?

[calvin-codecov]

This could create the possible scenario that the cleanup callback would be called multiple times at the same time though if each of the tasks fails even though it tries to do the same thing on the same objects. There's no difference in what the cleanup does depending on what task failed since if any of the tasks fail, we want everything to cleaned up and marked as not usable, right? If that's the case, I think the old version would work better

[adrianviquez]

Ah I see what you mean, ya that's a good insight. I'll address and have the whole chord throw an error if any of its sub-tasks has an error

[ajay-sentry]

send it

[cursor]

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.}

[cursor]

Removed error handling risks stuck exports

High Severity

The SQL, archives, and finalize tasks no longer mark exports as FAILED in their exception handlers, relying entirely on the cleanup task via Celery's link_error mechanism. If the cleanup task doesn't execute due to infrastructure issues, Celery bugs, or error callback failures, exports will remain permanently stuck in IN_PROGRESS status. Known Celery issues with chord error callbacks make this particularly risky.

Additional Locations (2)

• apps/worker/tasks/export_owner_data.py#L322-L334
• apps/worker/tasks/export_owner_data.py#L457-L469

 

[adrianviquez]

Given the scope of how often this task will run, it's okay for it to rely on the cleanup task for this