Safety checks

How Ridu classifies migration risks, which flags approve destructive or traffic-sensitive work, and what each safety code means.

ridu migrate create reviews every change before it writes a migration. Anything worth a second look is recorded in the file’s risks, with a level that decides what happens next:

Level	Meaning	What happens
`notice`	Context for whoever deploys it	Recorded in the file.
`warning`	Deserves review before you deploy	Recorded in the file and printed by `create`.
`destructive`	Can permanently remove stored data	`create` stops until you approve it with `--allow-destructive`.

Some changes are refused outright, whatever the flags. Those report one of the safety codes below.

Approval flags

Each flag approves one thing at one step. None of them silences a safety code.

Flag	Used on	What it approves
`--allow-destructive`	`create`	Writes a reviewed destructive change into the migration. It doesn’t connect to a database.
`--allow-destructive`	SQLite `down`, `reset`, `refresh`, `fresh`	Rolls back or rebuilds the selected database.
`--allow-maintenance`	`up`	Runs traffic-sensitive steps. Only pass it after every old process, writer and worker has stopped.
`--allow-insecure-database`	database commands	Connects to a remote PostgreSQL or MongoDB development host without verified TLS.
`--allow-unbounded`	`up`, `verify`	Allows a zero wait or timeout where one would otherwise apply.

--allow-maintenance is a promise that old writers are stopped, not a lock that stops them. Keep them stopped through retries until ridu migrate status reports the history complete. verify never needs it, because it replays into a private database no application can reach. Which steps count as maintenance is covered in Deploy migrations.

A loopback or Unix-socket database never needs --allow-insecure-database, and the offline create command rejects it.

Removing a collection or field

On SQLite, migrations can only add to the schema, so removing a field or collection is refused:

terminal

$ ridu migrate create --name remove-summary --allow-destructive
plan migration: SQLite artifact planner supports only additive
transitions; field "posts-summary" in collection "posts" was removed

On PostgreSQL and MongoDB, removing one is destructive. Removing a collection can need approval twice: --allow-destructive when you create the migration, and --allow-maintenance when you apply it, because the runner also purges the sessions, credentials, versions, tasks, preferences, locks and reference-index entries the collection owns.

Removing an upload collection is refused even with --allow-destructive. A migration can’t move or delete the stored files, so do that first, as described under RIDU_UPLOAD_COLLECTION_REMOVAL_UNSAFE below.

Safety codes

Codes are stable, so you can match them in CI policy and runbooks. Each one names a change that is unsafe as written, not a check to work around.

RIDU_MIGRATION_PLAN_MISMATCH: The migration file no longer matches the plan Ridu rebuilds from its contents. Restore the reviewed file or create it again; don't apply the changed one.
RIDU_REQUIRED_VALUES_MISSING: Stored documents have no value for a field that becomes required. Backfill them with a data transform, or keep the field optional. See Required fields.
RIDU_VERSIONS_EXISTING_REQUIRED: A collection or global starts keeping versions, and the migration doesn't say what its stored documents become. Pass --versions-existing=published, draft or require-empty, or answer the question in a terminal. See Enabling versions.
RIDU_VERSIONS_ENABLE_NOT_EMPTY: A migration that enables versions with require-empty found stored documents. See When require-empty stops.
RIDU_VERSIONS_EXISTING_DOCUMENTS: ridu dev would enable versions on a collection that stores documents without a decision about them. Save again in a terminal to choose, or create the migration with --versions-existing.
RIDU_REFERENCE_SHAPE_DECREASE_UNSAFE: Narrowing a relationship's field, target or cardinality could leave dormant references in current values or version snapshots. Keep the shape, retire the whole owning resource, or write an application-owned cleanup first.
RIDU_REFERENCE_RENAME_MAPPING_AMBIGUOUS: A source or destination field is mapped more than once. Split the change into unambiguous migrations.
RIDU_COLLECTION_SLUG_REWRITE_OVERLAP_UNSAFE: A chain or swap of renames could rewrite one value twice. Go through a unique temporary slug, in separate reviewed migrations. See Renames.
RIDU_UPLOAD_COLLECTION_REMOVAL_UNSAFE: A database migration can't manage stored files. Move or delete them through upload operations, reconcile the result, and verify matching backups before removing the collection.
RIDU_AUTH_DISABLE_STATE_UNSAFE and the other *_DISABLE_STATE_UNSAFE codes: Turning off auth, API keys, password reset, email verification, versions, drafts, document locks or trash would leave dormant state that could come back later. Keep the capability enabled, or add the cleanup the finding names.
RIDU_RETIRE_DEPENDENT_VERSION_HISTORY: Retiring a resource also deletes the version history of documents that depend on it. Include that loss in your backup, review and sign-off.

Troubleshooting lists more failures by symptom.