Stopping previous actor before spawning new actor with same ID?

[lewisl9029]

Hi there!

I've been working on a file-watching machine that spawns actors to process each file's change event, using the file path as the actor's id. The processing actor involves some async work, including file io and network requests, that I'd like to cancel/abort when new change events come in for the same files. I haven't quite been able to figure out how to cleanly stop the previous actor that's still active before starting a new actor for the new events.

Here's a minimal repro of my best attempt so far: https://codesandbox.io/s/thirsty-easley-xx6mi8?file=/src/index.js

We can see from the console logs that the update event sent 1 second later results in the following warning:

Warning: Event "initialize" was sent to stopped service "updateMachine". This service has already reached its final state, and will not transition.
Event: {"type":"initialize","id":"1","params":{"data":2}} 

And after 3 seconds, the original update event will have been processed to completion, judging from the params: { data: 1 } event payload.

Would really appreciate some ideas on how I can get this to work. Thanks!

P.S. any reason why there's no equivalent for the data arg for spawning machines with some initial context? I have a feeling the initialize event might be making things more difficult than they need to be for my use case.

[davidkpiano]

If you add preserveActionOrder: true to the root of the machine, that may help; that works by ensuring that the stop(...) action is called before reassigning that actor.

P.S. any reason why there's no equivalent for the data arg for spawning machines with some initial context? I have a feeling the initialize event might be making things more difficult than they need to be for my use case.

This would essentially be the same as this:

[event.id]: spawn(updateMachine.withContext({/* custom initial context */}), event.id)

And you can read from both the parent's context and event to get that initial context, which are both in scope.

[lewisl9029]

Thank you so much for these tips! Glad to see preserveActionOrder will become the default in v5 so this kind of use case can be a bit more intuitive!

I gave both preserveActionOrder and withContext a try in this fork: https://codesandbox.io/s/gifted-heisenberg-n1n7cd?file=/src/index.js

But unfortunately I still haven't managed to get it to work as intended. We still see data: 1 coming from the final updated event, indicating the first actor executed to completion.

Interestingly enough, I added some logs on the cleanup steps of the spawned callback in the update machine, and from that we can see for some reason the 2nd actor ends up getting cleaned up as soon as it gets created! It sounds like the stop event might be getting sent to both the newly spawned and the original, despite the preserveActionOrder setting, possibly due to the fact that they have identical IDs?

Curious if you'd consider this a bug in xstate, or if reusing the same ID for a new and recently stopped machine just isn't a supported use case?

One alternative approach I've been thinking about is spawning actors with ids in the format of (${event.id}-${some-random-string}), and then stopping all existing actors prefixed with ${event.id}- before spawning the new one. That way the stop events are guaranteed to to never refer to the new actor by ID, which seems to be what's causing issues here.

Life would be a bit easier if reusing the same ID just worked, but I wouldn't mind refactoring if this is not easy to support. Let me know either way, or if you have suggestions for a better approach. Thanks!

[Andarist]

It seems like a bug. I'm gonna investigate this soon. I'm actually currently working on some internal refactor related to spawn and invoke. It is meant to fix some long-standing issues and I also think that it's going to fix this one. I need to confirm that though.

[Andarist]

I've managed to diagnose the issue - right now spawn is called eagerly, but stop is lazy. So spawn manages to replace a child (with the same ID) before stop is actually executed.

The mentioned refactoring that I'm working on currently will address this issue and I will make sure to include a test case like this to guard us from any potential regressions in the future.