-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed an issue with actors not being reinstantiated correctly in a microstep #3374
Conversation
🦋 Changeset detectedLatest commit: 59c48cb The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 59c48cb:
|
👇 Click on the image for a new way to code review
Legend |
state.actions.find((otherAction) => { | ||
return ( | ||
otherAction.type === actionTypes.stop && | ||
(otherAction as StopActionObject).params.actor === id | ||
); | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was the main source of the problem because we had actions looking like this:
actions: [stop('a'), invoke('a')]
Stop action for 'a'
was simply found in the array and thus the actor was never reinstantiated - despite of the fact that the invoke was coming after it.
? params.actor(context, _event.data) | ||
: params.actor; | ||
: state.children[params.actor]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have to resolve a string to the ref here, before we mutate the new children in setChildren
that was added here:
https://github.com/statelyai/xstate/pull/3374/files#diff-6f3a03f5c8d5024e53467d74c187685ab0acd0e1efb2549fbf2842d9616ad8dbR1635
Because that setChildren
removes stopped children from what is going to become service.state.children
we are no longer able to resolve it in the "stop handler" here:
https://github.com/statelyai/xstate/pull/3374/files#diff-fc91146eff717b2bcd6adbc0955ca0549346ad7bef9aa2278e0a75a9793a66b9L683
@@ -305,6 +306,8 @@ export class StateMachine< | |||
preInitial._initial = true; | |||
preInitial.actions.unshift(...actions); | |||
|
|||
setChildren(preInitial.children, actions); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The preInitial
wasn't previously populated with children and thus without this change we were failing the adjusted logic here:
https://github.com/statelyai/xstate/pull/3374/files#diff-fc91146eff717b2bcd6adbc0955ca0549346ad7bef9aa2278e0a75a9793a66b9R656
) { | ||
// If the actor didn't end up being in the state | ||
// (eg. going through transient states could stop it) don't bother starting the actor. | ||
if (!this.state.children[id]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since state.children
are mutated in setChildren
"in order" it should be enough to just check if the final result contains the given id or not.
fixes #3353