Fixed an issue with not being able to send events to initially started child actors when using predictableActionArguments

[Andarist]

fixes #3548

[changeset-bot]

🦋 Changeset detected

Latest commit: 0f1328c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
xstate	Patch

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

[ghost]

👇 Click on the image for a new way to code review

• Make big changes easier — review code in small groups of related files

• Know where to start — see the whole change at a glance

• Take a code tour — explore the change with an interactive tour

• Make comments and review — all fully sync’ed with github

  Try it now!

Legend

[codesandbox-ci]

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 0f1328c:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration
gifted-dewdney-yg4mee	Issue #3548

[Andarist]

The problem here was that executing initial actions is still done using Interpreter#execute - and doesn't happen from within StateMachine#transition:

xstate/packages/core/src/interpreter.ts

Lines 322 to 336 in 0f1328c

	// Execute actions
	if (
	(!this.machine.config.predictableActionArguments ||
	// this is currently required to execute initial actions as the `initialState` gets cached
	// we can't just recompute it (and execute actions while doing so) because we try to preserve identity of actors created within initial assigns
	_event === initEvent) &&
	this.options.execute
	) {
	this.execute(this.state);
	} else {
	let item: typeof this._outgoingQueue[number] | undefined;
	while ((item = this._outgoingQueue.shift())) {
	item[0].send(item[1]);
	}
	}

So initial send actions were never sent out after my recent PR: #3540 where I've introduced _outgoingQueue

[davidkpiano]

Was the problem that it was not sent immediately, or not sent at all?

[Andarist]

they would be flushed within the next service.send(ev) - which could happen at any time, or not at all.

[davidkpiano]

In real-life scenarios, we can't assume that this is synchronous. Will the machine still get the PONG event after it settles on the initial state (it should)?

Maybe we can test this by instead listening for .onDone(done) so we don't depend on it being sync 🤔

[Andarist]

In real-life scenarios, we can't assume that this is synchronous. Will the machine still get the PONG event after it settles on the initial state (it should)?

Yes, in this case, the test case is really more about the child receiving an event than about the parent receiving the response - I could slim it down.

Maybe we can test this by instead listening for .onDone(done) so we don't depend on it being sync 🤔

I agree that those conceptually are async. However, I think that we also need to test synchronous logic as sync code often exposes more edge cases in scheduling etc. So it feels more beneficial to prefer sync tests in our test suite when possible - despite the mental model being async.