runs.unavailable

The app's unfinished runs couldn't be read from their database, because it can't be reached or has no table for them yet.

Area 14, Tools; not declinable; the next step is usually the human's.

Why Jadpo refuses it

jadpo runs unfinished is run against production before a deploy. It reads the unfinished multi-step runs and batch runs from the tables Jadpo keeps them in, and lists those the new build changes, so you know what will stop. Those tables come with the project's migrations. When the database can't be reached, or has no such table, the command can't say what the deploy changes, so it stops rather than list nothing.

Jadpo won't apply the migrations for you here or try another address. The database is likely production's, and whether it is the right one only you know.

What it looks like

A project whose take_stock walks every item in batches:

domains/stock/actions/take_stock.jadpo:

use stock/types { ItemPage }use stock/actions { mark_seen }use stock/queries { items }/// Marks every item as seen, a batch at a time.action take_stock(page: ItemPage) -> BatchRun {    return batches.each(from: items(page), each: item -> mark_seen(item))}

--build names the build being deployed by its build id, which jadpo check writes in build/manifest.json for each deployable. Here it is read from there, and DATABASE_URL names a new database, to which the project's migrations haven't been applied:

jadpo checkbuild=$(grep -o 'b_[0-9a-f]\{12\}' build/manifest.json)jadpo runs unfinished --build "$build"

checked: 8 fileserror: The database `main` has no table for unfinished runs yet  reason: `jadpo_batch_runs` comes with the project's migrations, so either the database hasn't applied them, or it isn't this project's database.  next: Run `jadpo migrate apply` if it is this project's database, then run the command again (human)  rule: runs.unavailable  help: https://jadpo.dev/docs/errors/runs.unavailable

(human) at the end of the next: line tells your coding agent to stop and ask you which fix you want, because the choice is yours to make: it decides which database the command reads, and whether its schema changes.

A database whose server isn't running gives the same error, saying it can't be reached. Here DATABASE_URL names a database on a port where no server is listening:

jadpo checkbuild=$(grep -o 'b_[0-9a-f]\{12\}' build/manifest.json)DATABASE_URL=postgresql://localhost:5499/stock jadpo runs unfinished --build "$build"

checked: 8 fileserror: The database `main` can't be reached  reason: Connecting to it failed, so no unfinished runs could be read.  next: Check the database is running and its address is right, then run the command again (human)  rule: runs.unavailable  help: https://jadpo.dev/docs/errors/runs.unavailable

How to fix it

The question is whether the address names this project's database.

If it is this project's database, not yet migrated, apply the migrations, then run the command again:

jadpo migrate applyjadpo runs unfinished --build "$build"

The tables are made, and the command lists what the build changes: nothing, on a new database.

If its server isn't running, start the server, then run the command again:

jadpo runs unfinished --build "$build"

The command reaches the database and lists what the build changes.

If the address names another database than production's, name production's with --url:

jadpo runs unfinished --build "$build" --url "$PRODUCTION_DATABASE_URL"

The command reads that database instead, and leaves the other alone.

Related

• jadpo runs unfinished
• Deploys
• jadpo migrate