The delivery seam a completed invoke goes through - the run-liveness check at the done.invoke door, the same shape StatifierOban.Timer.Delivery gives a fired timer.

When an invoke-handler job (StatifierOban.Invoke.Worker) finishes its work, the result has to travel back into the run as done.invoke.<invoke_id> with donedata. A durable job survives the run it was started for, so before feeding anything back the host MUST establish the run is still live and discard otherwise - a completed invoke against a dead or halted run is discarded exactly the way a fired timer is. The guarantee is enforced here, at delivery time.

Whether a run is live is the host's question, not this package's: a host running Statifier.Session processes answers it from the session registry and delivers through Statifier.Session.done_invocation/3 (StatifierOban.Invoke.Delivery.Session, the default), while a process-less host driving Statifier.Interpreter against persisted positions answers it from its own run store and feeds the completion into its next drive. That is why this is a behaviour: StatifierOban.Config carries the implementation (:invoke_delivery), and the enqueued job carries it to the worker.

What this seam does not resolve

A delivery module answers for the invocation that just finished, and for nothing else. In particular it never chooses a handler, and there is no per-delivery handler map to configure - not here, not on StatifierOban.Config, not in the job args. An <invoke>'s handler is chosen by the engine, one drive at a time, out of that run's :invoke_handlers registry (st-ADR-0051 decision 4); by the time this package is involved the module has already been chosen, and StatifierOban.Invoke.Handler's perform/2 has written its name onto the job row for StatifierOban.Invoke.Worker to read back.

That matters most at the second step. When deliver/3 feeds done.invoke.<invoke_id> back and the run transitions into another invoking state, the <invoke> entered there is planned by the drive this delivery caused - so its handler comes from whatever registry that drive was given. A Statifier.Session host fixed one at start_link/2 and every step sees it. A process-less host supplies one per drive, and the re-entry drive is a drive like any other: give it the same map the run started with, or the second <invoke> raises error.execution at plan time on an unregistered type while the first step looked perfectly healthy. The seam is not the place to fix that, because the seam was never asked.

The seam has two doors, not one. deliver/3 carries a completed invocation back as done.invoke.<invoke_id>; deliver_failure/3 carries a permanently failed one back as error.communication.invoke.<invoke_id> (st-ADR-0068), which is what a chart parking failed work for operator recovery transitions on. Both run the same run-liveness check first, because a durable job outlives the run it was started for either way.

Implementations must be idempotent under redelivery: jobs in this package are at-least-once, so deliver/3 can run more than once for the same completed invoke. The default implementation gets that from Statifier.Session.done_invocation/3 itself, which documents a second call for the same invoke_id as a harmless no-op.

Carrying the caller's trace context

caller_context (st-ADR-0063) is the opaque host slot the macrostep that executed the <invoke> stamped onto the effect. It rides the job args untouched (StatifierOban.Invoke.JobArgs) and is on the %Statifier.Effect.Invoke{} the worker decodes days later, on another node, byte-identical to what was enqueued. The answer event owes it onward, unchanged, exactly as StatifierOban.Timer.Delivery says a fired timer's event does: upstream puts the answering event's caller_context on the macrostep telemetry the answer drives ([:statifier, :session, :macrostep, :start | :stop]), which is what lets opentelemetry_statifier link the completion back to the trace that started the invocation instead of leaving it detached. Drop the slot and the link is lost at the last hop, silently.

Which door gets it depends on who builds the event, and that differs from the timer half:

• A host driving Statifier.Session does not build the event at all - Statifier.Session.done_invocation/3 and failed_invocation/3 build it inside the session and inherit the slot from the session's own invocation table (st-ADR-0063). There is nothing for such an implementation to carry, which is why StatifierOban.Invoke.Delivery.Session implements only the three-argument doors.
• A process-less host builds the event itself, with Statifier.Invoke.Answer.done/4 or failed/4, and has no invocation table to inherit from - the job row is its record of the invocation. That is what deliver/4 and deliver_failure/4 are for: the same two doors, handed the slot off the row, to pass straight into the builder's caller_context: option.

Two arities per door

Each door has a three-argument form and a four-argument one. The three-argument forms are the contract and stay required; the four-argument forms are optional, and StatifierOban.Invoke.Worker calls the widest one a delivery module exports - the same "define the wider arity when the work needs what it carries" shape StatifierOban.Invoke.Handler gives run/1 and run/2. A module defining both runs through the four-argument form, and its three-argument clause is dead code kept for the behaviour; a one-line delegate is the usual way to satisfy it:

@impl StatifierOban.Invoke.Delivery
def deliver(scope, invoke_id, donedata), do: deliver(scope, invoke_id, donedata, [])

An existing implementation that defines neither four-argument form is unaffected and keeps being called exactly as before. That is the whole reason the widening is an added arity rather than a changed signature: every StatifierOban.Invoke.Delivery written against 0.5.0 still conforms.