The seam every outside call goes through

Every call that leaves your app's process, to a capability or to a provider, goes through one entry point in the runtime: the seam. This topic is how the seam carries out Capabilities the built-in services use, A send whose outcome is unknown and Outside calls hold no transaction.

One way out

Both executors call the same entry point. A driver is named by the connection it serves (Connecting in app.jadpo) and answers in one of five ways:

• a value;
• one of its operation's own failures, which the call maps;
• surely did nothing;
• may have acted;
• misconfigured.

A call to a connection that no driver fills is misconfigured and is never sent.

Logged without its values

Each call is logged as it goes out, and again when it is answered. The log has its connection and operation, and whether it may be sent again: it changes nothing, it changes something under a key, or it changes something with no key. It also has where its answer came from (the driver, a fake or a replay), when it went out, how long it took, and how it ended.

The log never has the call's input or its answer, which can hold secrets and personal data. jadpo calls's full values in development are kept apart, by jadpo dev's host only (Provider calls in development: jadpo calls). A response carries its request's log.

Recorded and replayed

A recording keeps each call's answer, in order, beside the random bytes it keeps. A replay gives the answers back without the calls going out. A replayed call that isn't the recording's next one is refused before it goes out.

outcome_unknown only where a repeat could act twice

A call that may have acted raises outcome_unknown when it changes something with no key. One under a key, or one that changes nothing, raises unavailable, since sending it again acts only once.

A delivery can go to a capability

Besides running a subscriber's action, a delivery can hand its event whole to an operation of the capability a connection fills, as an EmailMessage's delivery does. Its record alone says it was sent: there is no action, so there is no handled record.

Parked, never sent again blindly

A delivery is parked as outcome_unknown for an operator when its send may have acted and has no key (What an operator sees). That happens when its driver said so, when its run's time ran out while the send was out, or when its worker was lost while it was out. An unkeyed send is marked sending on its delivery record before it goes out, so the sweep parks a delivery whose lease passed instead of claiming it again.

• A subscriber's action that sent such a call and then ended in a way that is otherwise retried, such as a store that couldn't be reached or its time running out, is parked too, since a retry would send the call again. One that fails for good stays failed.
• After a concurrent change, an action that sent such a call is never run again (All-or-nothing actions and concurrent changes). It stops as outcome_unknown, which a route keeps for its client's key and a delivery parks (Several changing calls in one action).
• A send under a key, or one that surely did nothing, is retried as any delivery is.
• A lost worker. A subscriber's action whose worker is lost while its call is out is handled by the step record (Several changing calls in one action).
• A schedule's run has no retry to stop, since its next run is the next tick's, so its run record keeps how it ended.

No call inside an open transaction

What the action has only read is a snapshot, which the call closes. A call made once the action has written, while its transaction is open, is refused before it goes out, with a fault naming the call and saying to make it before the action's first write (Outside calls hold no transaction). The checker proves the order. Calls made by a batch's items run inside their batch's transaction, and are refused the same way.

Fakes wrap the host

A fake is a wrapper around the host that puts a scripted driver in place of some connections, and leaves everything else as the host's own. A test runs on it, and jadpo dev's host gives a package's fake the same way. The runtime's Rust tests share one test host, which fakes wrap the same way.