I current have the current flow:
- Parent workflow 1
- child workflow [ have a mutex to lock the resources, and has a defer will trigger the unlock ]
- child workflow [ this workflow is blocked till mutex is unlocked] - Parent workflow 2
- similar setup with the child workflow as above where the mutex if locked in workflow 1 would block the child workflow here
There two possible scenarios:
- Send a cancel on workflow 1. This should cancel the child workflows and unlock the mutex.
- Send a cancel to workflow 2. In this case, the mutex is still being blocked by workflow 1. Will the cancel wait till the mutex is unlocked?
I’m seeing this comment as well, leaving me to believe that it’s being held back. Wanted to get a better understanding why a cancel would be queued up vs. being triggered right away or is there edge cases that I need to factor in.
Cancel Request Sent
The request to cancel this Workflow Execution has been sent. If the Workflow uses the cancellation API, it'll cancel at the next available opportunity.