Bug: Cron Job Feature - Instant Retries on Exceptions and Absence of Default start_delay
Closed this issue · 0 comments
Description
During my recent work with the Cron Job feature, I've discovered two important issues that need to be addressed to improve the robustness and usability of our system.
Bug 1: Instant Retries on Exceptions
At the moment, if an exception is thrown during the execution of a cron job and it's not handled properly, the job instantly retries. This behavior diverges from the intended functionality, where a cron job should wait until the next scheduled interval before retrying, thus avoiding potential resource exhaustion.
Current behavior: Cron job retries immediately when an unhandled exception is encountered.
Expected behavior: The cron job should only retry after the set interval has completed.
Bug 2: No Default start_delay Value**
The current system design mandates the specification of the start_delay variable when initiating the cron job. If it's not set, the system raises an exception. To enhance user experience and system resilience, we should implement a default value for start_delay to be used if none is provided by the user.
Current behavior: The system throws an exception if start_delay is not set.
Expected behavior: The system should default to a start_delay of 0 if none is provided.