Waits for the process's end and fails with its failure; never succeeds.
The failure the process ended with, once it ended.
Succeeds while the process runs; once it ended, fails with the failure it
ended with — the session-fatal error itself, typed (the same object), and
any other end (a stop of the call, a timer's defect) as a defect. The one
reading of "the process has ended" for what comes after the end: the request
path refuses every request with it before the network, and the background
set's wait (MobileProcessBackground.settled) fails with it, so a program
that composes the layer itself learns the end from its next call or from
that wait.
Ends the process with failure; the first failure wins and later ones are ignored.
The one rule "a session-fatal answer to a background request ends the
process": ends it with the first session-fatal failure cause carries and
says whether it did. Every background work of the process applies it — the
set's hand-over (MobileProcessBackground.handOver, the launch's tail), a
transition hook's request and a timer's — and none writes its own copy.
A cause with no session-fatal failure (an ordinary failure, a defect, an
interruption) ends nothing.
ProtectedonA platform's hook: what else stops when the process ends (its own fibers).
The app process a request ran in, as an opaque value. A platform's app layer installs its own subclass (it knows its process's services; this neutral layer knows none of them), and the transport attaches the value to the failures that continue in the same process — a checkpoint, whose challenge the platform opens as screens of that process (
OpenChallenge(error)on Android). It is opaque: a caller has nothing to do with it.It also carries the process's end. A failure the process cannot go on after — a session-fatal answer of its own background work (a timer, a transition hook, the launch's tail: a checkpoint, a lost login, a suspended or disabled account), or a tail request's challenge the call's
otherwisecannot settle — ends it:end(failure)records the first such failure (AppProcessReference.endIfSessionFatal is the one rule that decides a background work's failure is session-fatal; the background set's hand-over also ends it with the stop of an unsettled challenge); the request path and the background set's wait refuse from then on with it (AppProcessReference.stillRunning), and the run that owns the process races the start and its program againstendedand readsendedByonce more after the wait — so the program stops with that failure, or, when it already returned, the call rejects with it — and the process closes in the app's order (pending telemetry, connections, runtime) — one owner of "the app closed".