Replies: 12 comments
-
Thanks for the great repro case! Things like this shortens the feedback loop for reporters - they allow us, maintainers, to jump into answering much quicker (or at all, as we just can't always afford to setup repros on our own and issues get lost). issue number 2 (the third test in your repro)it's not the parent machine that fails, but it's rather the inner machine (the one that has We might want to introduce better event filtering for issue number 1 (the forth test in your repro)I think this happens because the child machine reaches its final state DURING forwarding (eh, those pesky synchronous edge cases 😠). I will yet have to confirm this in full, but if that's the case then the fix will be quite straightforward. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick response! I had a suspicion that |
Beta Was this translation helpful? Give feedback.
-
I've diagnosed the issue number 1 further - it's actually simpler than I have thought.
I think the best that we could do is to implement removing the stopped child from the children collection, but currently, it seems that this might be harder than I would have thought. The problem is that we don't have access to our own children's statuses, because they are just Actors and those don't expose such information. There also might be children with the same ID in different interpreters so we cant just remove a particular child upon receiving My best bet right now is to introduce a special global semaphore-like flag that would be able to silent those warnings, because we still want to have this warning when a user sends an event directly to a stopped machine, but at the same time we dont want to show it if it happens during our internal processing. @davidkpiano WDYT? |
Beta Was this translation helpful? Give feedback.
-
I have a somewhat related problem. I have a service that spawns actors which eventually go into a 'final' state. I have a cleanup function in my Any advise on how to handle this properly for now? |
Beta Was this translation helpful? Give feedback.
-
You could experiment with |
Beta Was this translation helpful? Give feedback.
-
This is another thing I'm not too sure about: isn't it redundant to stop a service that is already in its final state? Is your line of thinking that As for pure, I'm not too sure how to use it #1014 |
Beta Was this translation helpful? Give feedback.
-
Well, we probably should clear children automatically upon receiving I've looked into the problem with |
Beta Was this translation helpful? Give feedback.
-
I'll look into why |
Beta Was this translation helpful? Give feedback.
-
Let me know if this is unrelated and I'll log a separate issue. @davidkpiano I agree. Question is, how do I (as a developer) remove a child that I no longer have a need for (so that it isn't autoForwarded any further events)? Have a look at this (instructions included). The point I'm trying to make is, there doesn't seem to be a way to remove stale actors: |
Beta Was this translation helpful? Give feedback.
-
Oh, this repro explains to me your problem - you should not call imperatively things on your actors. Use events! It's hard to quickly adjust your demo because of the Apart from that, I've noticed why we don't clear things correctly and gonna prepare a PR for it in a moment. |
Beta Was this translation helpful? Give feedback.
-
Ok I think we're on the same page. In real life, my actors are sent events and the actors themselves decide whether to go into a 'final' state or not. My confusion up to this point was this: when an actor is in a final state, is it up to the developer to clean things up? It seems at this point, the answer is NO and that |
Beta Was this translation helpful? Give feedback.
-
Exactly 👍 |
Beta Was this translation helpful? Give feedback.
-
Bug or feature request?
Potentially a bug, but could just be incorrect implementation patterns
Description:
I'm currently working on a complex admin application which requires heavy use of hierarchical machines and parallel states; essentially, we have a main
parent
machine for each page in the admin, and each modal/banner/etc within that page gets spawned as a child machine or parallel state. The modals and banners talk to their respective machines by sending events through the parent machine. We've been usingautoForward
to reach these invoked machines in order to cut down on the high amount ofsend
actions that would be required otherwise. However, in doing so, we've stumbled across some behavior that is either a bug or simply an issue with this pattern which we've been implementing. If it's the latter, then I'd very much be interested in discussing the recommended patterns for the examples below.Issue 1: When a child machine is invoked and reaches its
final
state, theonDone
transition will throw a warning in console:Warning: Event "done.invoke.childMachineInvoke" was sent to stopped service "childMachine". This service has already reached its final state, and will not transition. Event: {"type":"done.invoke.childMachineInvoke"}
Note: I noticed in testing that this warning does not pop up if the child machine reaches its
final
state via adelay
as opposed to an explicit event call.Issue 2: When a
Promise
in invoked within a state and hitsreject
, the resultingonError
event will break with an error in the console:Missing onError handler for invocation 'failingApiCall', error was 'Error: Api call failed!'. Stacktrace was 'Error: Api call failed!
Note: This issue can be worked around by setting up the call within its own machine as opposed to a state.
Link to reproduction or proof-of-concept:
https://codesandbox.io/s/hopeful-sinoussi-k75h7
Beta Was this translation helpful? Give feedback.
All reactions