# 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](built-in-service-capabilities.md),
[A send whose outcome is unknown](email.md#a-send-whose-outcome-is-unknown) and
[Outside calls hold no transaction](all-or-nothing-actions-and-concurrent-changes.md#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`](connecting-in-app-jadpo.md))
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`](provider-calls-in-development-jadpo-calls.md)).
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](what-an-operator-sees.md)).
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](all-or-nothing-actions-and-concurrent-changes.md)).
  It stops as `outcome_unknown`, which a route keeps for its client's
  key and a delivery parks
  ([Several changing calls in one action](several-changing-calls-in-one-action.md)).
- **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](several-changing-calls-in-one-action.md)).
- **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](all-or-nothing-actions-and-concurrent-changes.md#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.