OnTime always built scheduledTimestamp from the date of the current tick, so
a tick that skipped the 23:59 minute compared it against 23:59 of the next
day. The run was dropped without a trace. Fall back to the previous day when
the scheduled time lands in the future.
Registered jobs are third party callbacks and were invoked bare. An error inside
one propagates out of OnTime into Tick, so Tick never reaches its
SetTimeout(60000, Tick) at the end and nothing ever reschedules it. From that
moment cron is dead for every resource on the server - paychecks, cleanups,
anything registered through cron:runAt - until a restart. The operator sees one
stack trace and then silence.
Wrapping the callback keeps the loop and the reschedule intact, and names the job
that failed.
Simulated the scheduler chain in standalone Lua with three jobs where the first
raises: before, the tick died before SetTimeout and the two later jobs never ran
again; after, the failure is reported and both later jobs fire.
Description:
This commit brings substantial enhancements to the time handling functionality in the 'esx_core/[core]/cron/server/main.lua' script for the FiveM server:
- Utilized Unix Timestamps: Replaced the existing `GetTime()` function with `GetUnixTimestamp()`, ensuring precise time representation by using the Unix timestamp format (seconds since January 1, 1970). This change mitigates potential issues related to Daylight Saving Time (DST) transitions.
- Refined Task Execution Logic: The `OnTime` function has been refactored to operate based on Unix timestamps, ensuring accurate execution of scheduled tasks without any inconsistencies due to local time conversions.
By introducing these improvements, the cron-like system now operates with enhanced accuracy, bolstering the stability and predictability of scheduled events on the FiveM server. Extensive testing has been conducted to guarantee compatibility with various server environments.
_Not_