mirror of
https://github.com/hanzoai/tasks.git
synced 2026-11-02 10:43:08 +00:00
## What changed? - When acquiring workflow execution locks during workflow reset, check whether you already have the lock and if you do, use that instead of trying to get the lock reentrantly - Add a functional test that catches this bug ## Why? Previously, resetting the base workflow execution of a ContinueAsNew would trigger a `BusyWorkflow` error due to trying to lock a workflow execution that we already held the lock to. Having already locked the current workflow execution and the base workflow execution, `ResetWorkflow` would try to get a lease on the next workflow execution after the CaN. However, since that next execution was the "current," it was already locked, causing a `BusyWorkflow` resource contention failure. ## How did you test it? Reproduced the error with a test workflow and a functional test. No more error after implementing this fix. ## Potential risks <!-- Assuming the worst case, what can be broken when deploying this change to production? --> ## 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? Yes hotfix candidate