xstate: Error propagation from actions execution using interpreter
Bug or feature request?
Feature request / question.
Description:
Using the interpreter, sometimes there are situations where an action results in synchronous runtime error. In these cases the error is not displayed and is fully “swallowed” by the state machine / interpreter while blocking the machine from executing the transition (think of, for example, error occurring in onEntry action).
Such errors are incredibly hard do debug as everything seems to work - except for the machine not going forward.
How should error handling of actions / services / activities be done?
(Bug) Expected result:
Interpreter should have a mechanism for errors to be caught / propagate outside, or at least be logging them in a clear manner.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 6
- Comments: 19 (15 by maintainers)
I just found my way here because I was trying to figure out why we don’t get a proper sentry.io error from a service that fails in strict mode. Turns out that the error is just logged to console and not propagated to Sentry’s unhandled promise rejection handler. While logging is great for backend applications this happens in frontend code where we rely on Sentry error collection as it groups the errors based on callstack and other values.
As a side note the error logging does not respect source maps in Chrome as it’s concatenating a string like
console.error("Error: " + error). The error should be sent to the logger as an error object to allow Chrome to handle sourcemaps, ie.console.error("Error:", error).That’s a good question. I think that currently no
error.executionis being sent - we useerror.platform.<suffix>which allows us for scoping errors per state/invocations (error.executionis kinda “global” as per SCXML spec). However, there are cases when we actually should senderror.execution- i.e. when an error happens when invoking a guard.