if a new higher-priority request is received instead.
I guess the way you would extend the example is to have a workflow state where you have the current priority and when it receives the signal compare it to that. Then trigger a cancelation within the sideEffect.
I have another use case where instead of determining the priority, I want to do some logic where I just process the latest request workflow and cancel the in between. I thought I could do this by storing a workflow query state in the mutex workflow to track this. As the mutex workflow receives lock requests, the logic will only keep the latest workflow id that has requesetd a lock and cancel the rest. However, I’m running into issue trying to actually update the state even thou I see the log statement printed. I"m guessing this is due to the code being in a sideEffect or that the mutex lock is triggered using SignalWithStartWorkflow
I’m prob not understanding how the section of the code related to the sideEffect and the processing of the request-lock signal works.
After first workflow that locks the mutex execute, isn’t the code just blocked at line 124 until the release signal or timeout occurs. When a new workflow triggers, SignalWithStartWorkflow, releaseLockCh channel gets injected with a signal and line 100 gets executed. At least thats what i can tell from the code and log printouts. However, i’m not clear how that even works since the workflow is still blocked on line 124
I’ve started another thread to capture this: