cli.config_rotation_unavailable

The sealed rows jadpo config rotation counts couldn't be counted, because their database can't be reached or has no table for them yet.

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

Why Jadpo refuses it

jadpo config rotation says when the previous field key can go, by counting each sealed field's rows in its database. With no count there is nothing it can safely say, and removing the key too soon loses rows for good, so it stops rather than guess.

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

What it looks like

A project keeping one note sealed, against a new database to which its migrations haven't been applied:

use clinic/types { ClinicalNote }/// A consultation, whose notes only the application can read.entity Consultation {    id: Uuid    notes: ClinicalNote {        encrypted: true    }}

jadpo config set field_encryption_key --generatejadpo config rotation

(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: only you know which database this is.

How to fix it

If the database hasn't applied the migrations, apply them:

jadpo migrate apply

The command then counts its rows.

If it can't be reached, check it is running and its address is right, or name it yourself:

jadpo config rotation --url postgresql://db.example:5432/clinic

Keep FIELD_ENCRYPTION_KEY_PREVIOUS in place until the command can answer.

Related

• Rotating the key
• Migrations