Request Failures & Retries
Learn how Mergent handles task failures and retries over a ~27-hour window, and the ‘At Least Once’ delivery policy
To acknowledge receipt of a Task, your endpoint must return a 200 or 201 HTTP status code to Mergent. All response codes outside this range, including 3xx codes, indicate to Mergent that you did not receive the Task. This is considered a failure.
Retries
When a Task fails, it will be retried (i.e., sent back to your request URL) on the following schedule:
- Immediately
- 5 seconds later (Tasks created by Schedules stop here)
- 5 minutes later
- 30 minutes later
- 2 hours later
- 5 hours later
- 10 hours later
- 10 hours later (again)
After all of the retries have been exhausted (a total of ~27 hours, 35 minutes, and 5 seconds for regular Tasks, and ~5 seconds for Tasks created by Schedules), your Task will be marked as a failure.
Retries can be disabled in your project’s settings.
‘At Least Once’ Delivery Policy
Mergent’s ‘At Least Once’ delivery policy is designed to ensure maximum reliability in task delivery. By guaranteeing that each task is delivered at least once, we significantly mitigate the risks associated with network inconsistencies and application downtimes.
This robust delivery mechanism can lead to the same task being delivered multiple times. To address this, applications should implement idempotent task processing. Idempotency ensures that repeated execution of the same task does not lead to unintended consequences.
Why ‘At Least Once’ Is Preferable to ‘At Most Once’
Choosing ‘At Least Once’ over ‘At Most Once’ in task delivery is a strategic decision. ‘At Least Once’ ensures every critical task is definitely processed, even if it means handling duplicates. This is vital in systems where the cost of not processing a task (like missing a crucial notification or update) is higher than the overhead of handling it more than once.
In contrast, ‘At Most Once’ might seem efficient by avoiding duplicates, but it risks task loss if issues arise in the delivery process, which can be more problematic for many applications.
Essentially, ‘At Least Once’ prioritizes certainty and reliability in task execution, a key factor for robust system operations.