Remove pending fibers after yields complete #374
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was changed
Today in places where we wait in a workflow, like
wait_condition, we store theFiber.currenton a hash then weFiber.yield. But when the yield was interrupted by say a timeout or other raised error, we were not properly removing the fiber from the hash. Therefore, later when code happened that would have caused the fiber to properly be resolved, it is obtained from the hash andresumed. But it is no longer yielding there and may be yielding somewhere else. This isn't justwait_condition+ timeout, this could happen if you interrupted waiting for activity completion or anything similar to that too.So where we do this, we updated to make the
ensureblock after aFiber.yieldremove the fiber reference from the hash so we do not inadvertently resume it later.This is a fairly rare situation, basically only happens on interrupted fiber yields (basically a fiber raise like
Workflow.timeoutdoes). We added a test to prove this situation exists and the fix fixes it for wait condition (did not add tests for every permutation of yield we have).Checklist
Workflow.timeoutexpires on x86_64 #373