The router's resolved configuration: the host's repo, where this package's tables live in it, the bindings events are routed by, the module each delivery is handed to, and what that module needs to reach statifier_persistence.

new/1 takes a keyword list and returns {:ok, config} or {:error, reason}:

StatifierRouter documents what a delivery module must answer, and StatifierRouter.Delivery what the four options it requires must be. A configuration that names another delivery module may leave those four out; one it gives is checked all the same. :persistence_options is never required: a configuration that omits it carries no snapshot, which is what statifier_persistence reads as "the built-in set only".

The route registry, and the two routes on this struct

:route_adapters is ADR-0005 decision 2's registry: the named outbound destinations a chart reaches with <send target="...">, each mapped to the module that serves it. It is deliberately not spelled :routes. :routes already means something else here - it is one of :persistence_options, where it is Statifier.Send.Routes, the engine's point-in-time claim about which <send> routes are live - and ADR-0005 decision 6 closed that ambiguity by vocabulary rather than by renaming the engine's. route/3 resolves a name in a scope.

:send_type is the one type string StatifierRouter.SendHandler is registered under. Giving it is what puts send_types: into :persistence_options, as the Statifier.Send.Types snapshot built from that type string and that handler (ADR-0005, decision 6); the registry cannot supply it, because a registry maps a route name to an adapter and holds no type string. A configuration that gives both :send_type and a :send_types of its own is refused with {:declared_send_types, send_type} rather than one silently winning.

:on_complete names one route in that same registry, and a name absent from :route_adapters is refused with {:unregistered_on_complete, name} rather than missed on the one delivery that would have used it. It is what StatifierRouter.Delivery hands an execution's donedata to on the delivery that finishes the execution, inside that delivery's transaction; the README's "A finished execution reaches a sink" sets it beside the chart's own way of telling a sink.

An {:error, reason} from that route settles the delivery as {:error, {:on_complete, route_name, reason}} and rolls it back, the finishing step with it (ADR-0003, section 1). That is deliberate: a terminal execution has no error.communication transition left to take, so rolling back is the only way the hand-off is not lost. Its consequence is that a route that never succeeds is a poison pill. The delivery that would finish the execution never commits, so the execution stays at the position it held before that step; each time the source hands the same message over again, the step runs again, its effects reach the executor again, the route is called again and the delivery fails again, and the front sees a message that fails every time. An execution that would finish on create/4 is rolled back whole instead, and each new attempt creates it under a new execution id (ADR-0003, section 2). The route must therefore be safe to call again under the same idempotency key - the at-most-once obligation StatifierRouter.Route states - and must eventually succeed. Nothing in this package retries or holds a failed message, so the number of attempts is bounded only by the source's own redelivery policy (the producer's contract, StatifierRouter.Broadway's "Redelivery is the producer's contract").

What the checks here do and do not catch

:store must be built over this configuration's own :repo, so that StatifierPersistence.Executions.create/4 and StatifierPersistence.Executions.step/5 write through the delivery's transaction rather than opening their own (ADR-0003, section 1). A store over another repo writes outside that transaction, and the delivery's rollback then leaves the execution behind. new/1 catches the case it can see: a store whose resolved adapter options carry a :repo that is not this configuration's is refused with {:error, {:invalid_value, :store, store}}. Those options are statifier_persistence's own, and only its Ecto storage resolves a :repo into them, so a store built on any other adapter passes this check without being checked. On such a store the rule is the host's to keep, and keeping it is not optional.

:resolver and :executor are checked to different depths, on purpose. StatifierRouter.Resolver is this package's own behaviour, so a resolver module is held to it: loadable and exporting resolve/2 (StatifierRouter.Resolver.valid?/1). StatifierPersistence.Executor is the dependency's, normalized per effect by StatifierPersistence.Executor.run/3, so an executor is checked for the shape that option takes - a module name or an arity-2 fun - and the dependency's own dispatch rule is left to it. A host that wants the deeper check on its executor gets it from statifier_persistence, not from here.

Each binding given as a map or keyword list is built with StatifierRouter.Binding.new/1. The resolved configuration keeps the bindings in the order given: it is the order StatifierRouter.route/3 returns its outcomes in. A duplicate binding id is a fault of the list rather than of any one binding, so it is refused here, naming the duplicated id, before any event is routed (ADR-0001, section 1).

A %StatifierRouter.Binding{} in the list is trusted as StatifierRouter.Binding.new/1 built it and kept as given: it is not passed through StatifierRouter.Binding.new/1 again, so its programs are not recompiled and its fields are not re-checked. A struct built or altered any other way is the host's to keep valid. The two checks on the list as a whole, the reserved id and the duplicated id, apply to it all the same.

The four tables are the address table of ADR-0002 (addresses), the dedupe table of ADR-0003 (dedupe), the ledger of ADR-0004 (routing_ledger) and the subscription table of ADR-0007 (subscriptions); table/2 names each one under a configuration. StatifierRouter.Migrations creates them from the same two storage options, and put_meta/2 and queryable/2 point the schemas in StatifierRouter.Schema at them, so the DDL and the rows cannot disagree on a name.

iex> {:ok, config} =
...>   StatifierRouter.Config.new(
...>     repo: MyApp.Repo,
...>     delivery: MyApp.Delivery,
...>     prefix: "routing"
...>   )
iex> StatifierRouter.Config.table(config, :addresses)
"statifier_router_addresses"
iex> config.prefix
"routing"