ref(replays): Retry deletes on failure and record failed bulk delete jobs as failed #93996
Conversation
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #93996 +/- ##
==========================================
+ Coverage 83.04% 88.06% +5.02%
==========================================
Files 10462 10384 -78
Lines 605064 603247 -1817
Branches 23637 23233 -404
==========================================
+ Hits 502446 531254 +28808
+ Misses 102258 71525 -30733
- Partials 360 468 +108 |
I'm not clear what this means - does this PR enable retries, or only add the logic to be used in the future? Does spin mean try indefinitely, and are we doing that here? (my guess is no because of the REPLAY_GCS_RETRIES check) |
User-facing retry logic. I.e. someone can restart a failed task. |
…jobs as failed (#93996) Deletes may sometimes fail due to service flakes. We should make an attempt to retry. If we can't delete the replay go into the failed state. We should offer retry logic in a follow-up PR. Or a beat task to automate the retry. But if the error is deterministic then we'll just spin.
Deletes may sometimes fail due to service flakes. We should make an attempt to retry. If we can't delete the replay go into the failed state. We should offer retry logic in a follow-up PR. Or a beat task to automate the retry. But if the error is deterministic then we'll just spin.