# Commands for background work

These commands are for an operator: the person who looks after a running
app. They show what the app's schedules and event deliveries did, and let
you retry or stop what went wrong ([What an operator
sees](12-jobs-and-events.md#what-an-operator-sees)).

| Command | Does |
|---|---|
| `jadpo deliveries` | Lists, retries, dismisses, cancels and resolves schedule runs and event deliveries |
| `jadpo schedules` | Lists schedules; `run`, `pause`, `resume`, `history` |

## `jadpo deliveries`

`delivery` is a synonym, and it takes `--json`.

**What it lists.** A table of what is `failed` or `outcome_unknown`,
newest first, 20 to a page (`--page`). `--state` lists those `pending`,
`running`, `held`, `dismissed`, `cancelled`, `diverged`, `unfinished` or
`abandoned` instead. A delivery is `diverged` when a deploy changed the
steps of the action it was part way through. Above the table is an alert
line for each connection whose circuit breaker is holding deliveries; a
circuit breaker stops calls to a provider that keeps failing, for a time.
Below it are a footer and one hint.

Diverged deliveries and a route's unfinished steps are listed by
default. Parked queue messages are listed as `failed`, as
`queue <connection> · <Event>` with their reason as the code. A
multi-step run unfinished for a day gets an alert line, and `--json`
gives the metric on unfinished records.

**Acting on one.** `retry`, `dismiss`, `cancel` and `resolve <id> --done`
or `--not-done` take an id's last 8 hex digits. Each works only from the
states it applies to (`deliveries.wrong_state`, `deliveries.not_found`),
and each is logged with the operator's name and database role. A
schedule's failed run is retried through the app's tick, as
`jadpo schedules run` retries it. A parked queue message is retried
through the app's next tick, or dismissed.

**An action with several changing calls.** `show <id>` lists each step an
unfinished multi-step action recorded, never a request, an answer or a
key, and the one thing to do. `retry <id> --not-done` sends again a step
that is in doubt or failed, under its next key generation. `abandon <id>`
gives the run up ([Several changing calls in one
action](11-integrations.md#several-changing-calls-in-one-action)).

## `jadpo schedules`

Takes `--json`. Alone, it shows a table of each schedule's last run and
next due time, or `‖ paused`, the alerts that hold, and a footer. Each
entity's built-in purge schedule is listed too, as `Member.purge`, its
runs showing the records they purged ([Watching
schedules](12-jobs-and-events.md#watching-schedules)).

- `history <name>` shows 20 records a page (`--page`), grouped by day,
  then the metrics.
- `pause` and `resume` set the schedule's state.
- `run` runs it now in this process under its lease (`schedules.lease_held`,
  `schedules.run_failed`), but only against a running `jadpo dev`'s own
  database. Against a deployment it asks the deployment's own tick to run
  it and waits for its record (`schedules.no_tick`; [Running a schedule by
  hand](12-jobs-and-events.md#running-a-schedule-by-hand)).

The database is `--url`'s, the connection's setting's, or a running
`jadpo dev`'s. An unknown name is `cli.schedules_arguments`, with the
nearest.

Not built yet: `jadpo deliveries` doesn't list batch runs.