check_repeaters() task iterates repeaters
#34946
Closed
Task list completed / task-list-completed
succeeded
Aug 27, 2024 in 0s
4 / 4 tasks completed
All tasks have been completed
Details
Required Tasks
| Task | Status |
|---|---|
| Draft spec | Incomplete |
| Arguably related to not DDOS attacking CommCare Analytics: SC-3820 | Incomplete |
Adding a max_workers field to Repeater so that each repeater can reduce the number of outgoing requests sent in parallel to its API. If Repeater.max_workers is set to 1, payloads will be sent sequentially in chronological order. |
Incomplete |
Removing attempt_forward_now() and its tests. |
Incomplete |
| Tested locally | Incomplete |
| Testing on Staging | Incomplete |
| The migrations in this code can be safely applied first independently of the code | Completed |
| This PR can be reverted after deploy with no further considerations | Completed |
| Risk label is set correctly | Completed |
| The set of people pinged as reviewers is appropriate for the level of risk of the change | Completed |
this isn't actually a lock, so if somehow two process_repeater calls were made for the same repeater, it would still process simultaneously |
Incomplete |
| adds another database update on the repeaters table | Incomplete |
there was an error in HQ code (I think that's one possibility if the except Exception block was executed below in _process_repeat_record) resulting in None |
Incomplete |
or because the repeat record had an empty payload that caused it not to be sent resulting in Empty |
Incomplete |
| The payload is bad, not the remote endpoint, and has been cancelled. (Repeater should not back off.) | Incomplete |
Sending failed one time too many (exceeded_max_retries is True), and the payload has been cancelled. (Repeater should back off.) |
Incomplete |
| The ability to ensure that payloads are always send in chronological order | Incomplete |
Remote endpoints that are unable to support MAX_REPEATER_WORKERS concurrent requests |
Incomplete |
Loading