HttpStore: a run's state over orca ui's API, for a run on a remote worker (orca worker, orca.worker), which holds no database credentials.
A pipeline binary given ORCA_STATE_URL (the UI, https://..., or http
to this machine only) and ORCA_STATE_TOKEN (a worker token,
orca.workers) in place of ORCA_DATABASE_URL records its run through
this store: each RunStore call is a POST of JSON to
<ORCA_STATE_URL>/api/worker/store/<call> with Authorization: Bearer <token>, which the UI answers by making the same call on orca.state.PgStore
(orca.workers.store_call), so what is recorded, and every check made on
the way (the run still this process's, not cancelled, its heartbeat fresh
enough to commit), is the same code as for a run that writes to Postgres
itself. Encoded inputs and outputs travel as hex.
Retries. A call that can't reach the UI, or that it answers with a 5xx,
is retried as PgStore retries Postgres (orca.store.Backoff, for
ORCA_DB_RETRY_SECONDS); one refused (401 or 403: the token was revoked,
or the run is another worker's now; 409: the run was lost or cancelled) is
final, and the run stops. A fence (Store.fence) that can't be made within
half the stale limit refuses the commit, as over Postgres.
The heartbeat is a POST .../beat from a thread every beat, which the UI
answers with why the run must stop now, if the watchdog says so
(orca.state.beat_run); the process then exits, as over Postgres. With
ORCA_WORKER_PID set, the beat also checks that the worker that started
this process is still its parent: if it isn't (the worker was killed), the
process exits rather than go on beating, so the server sees the run's
heartbeat go stale and requeues it.
Only resume, status <run> and keep-log work over this store: a
worker's run resumes the run it was given, so run, which creates one,
and status without a run need the database.