You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The failure went like this:
* A child arrives.
* In the meantime, the parent enters `tryMakeCompletingSlowPath`
and remembers the current list of handlers, which is an empty
or a single-element one.
* The parent updates the state to the finishing one.
* The child enters the list.
* The parent traverses *an old list*, the one from before the
child arrived. It sees no children in the empty/single-element
list and forgets about the child.
Why, then, was it that this worked before?
It was because there was a guarantee that no new children are going
to be registered if three conditions are true:
* The state of the `JobSupport` is a list,
* The root cause of the error is set to something,
* And the state is already "completing".
`tryMakeCompletingSlowPath` sets the state to completing, and
because it updates the state inside `synchronized`, there was a
guarantee that the child would see either the old state (and, if
it adds itself successfully, then `tryMakeCompletingSlowPath` will
retry) or the complete new one, with `isCompleting` and the error
set to something.
So, there could be no case when a child entered a *list*, but this
list was something different from what `tryMakeCompletingSlowPath`
stores in its state.
0 commit comments