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).

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).

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).

• 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).

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.