# `Statifier.Invoke.Handler.Scxml`
[🔗](https://github.com/riddler/statifier-ex/blob/v2.10.0/lib/statifier/invoke/handler/scxml.ex#L1)

The built-in `type=scxml` (and long-URI, `http://www.w3.org/TR/scxml/`,
with or without its trailing slash)
`Statifier.Invoke.Handler` - `Statifier.Session.Effects.plan_invoke`'s
default entry for the built-in type set, not a name it special-cases
(ADR-0051 decision 4).

Every instruction below is exactly what `plan_invoke/3` produced directly
before this module existed, so `Statifier.Session.perform_instruction`'s
`{:start_child, ...}` clause, `Statifier.Invoke.Source.resolve/2`, the
6.4.3 child-datamodel seeding, and both process monitors are unchanged -
this module only names the seam they already sat behind.

`cancel/2` and `forward/3` return the `{:stop_child, invoke_id}`/
`{:forward, invoke_id, event}` instructions the planner once emitted
directly for `:cancel_invoke`/`:autoforward` effects, and both effects now
reach them through this seam rather than around it (ADR-0051 decision 6):
the `:cancel_invoke` and `:autoforward` arms of the internal planning
step in `Statifier.Session.Effects` read the invocation's own `type` from
the plan context's live `:invocation_types` map, look that type up in
`:invoke_handlers`, and land on this module whenever that lookup finds no
registered handler - the ordinary case for an invocation started as
`type=scxml`, and equally for a `cancel_invoke`/`autoforward` naming an
invocation no longer tracked at all. Both callbacks are therefore
reachable from `plan/2`, and routing through them changes nothing
observable for the built-in type, since they return the instructions the
planner used to emit itself. `perform/2` is not
implemented: every instruction this handler returns already has its own
executor clause in `Statifier.Session` (and its own no-op clause in
`Statifier.Replay`), so there is nothing for an impure `perform/2` to do.

---

*Consult [api-reference.md](api-reference.md) for complete listing*