mirror of
https://github.com/hanzoai/tasks.git
synced 2026-10-30 14:56:19 +00:00
Yichao YangandGitHub
9dda852c00
## What changed? <!-- Describe what has changed in this PR --> - Handle system time move backward case in timer task processing by using max(now(), task visibility timestamp) ## Why? <!-- Tell your future self why have you made these changes --> - Monotonic time is used in time.Time comparison only when both operands have monotonic time value. In our case, the timestamp stored/derived in/from mutable state doesn't have monotonic, thus the comparison logic will use wall clock time to decide if a timer task should be processed. If wall clock move backwards (after we verifies that now() > task visibility timestamp when submitting the task to the task scheduler), the timer task will be dropped and cause workflow to stuck. ## How did you test it? <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> - Unit tests ## Potential risks <!-- Assuming the worst case, what can be broken when deploying this change to production? --> - In worst case, we will execute a timer task logic earlier than expected. ## Documentation <!-- Have you made sure this change doesn't falsify anything currently stated in `docs/`? If significant new behavior is added, have you described that in `docs/`? --> ## Is hotfix candidate? <!-- Is this PR a hotfix candidate or does it require a notification to be sent to the broader community? (Yes/No) --> - Could be. But the bug should be very rare as the use millisecond precision when doing time comparison in timer task processing.