This command is not a tenant deletion, and uncleanly drops a

Error message

This command is not a tenant deletion, and uncleanly drops all controller state for the tenant.  If you know what you're doing, add `--unclean` to proceed.

What it means

storcon_cli's tenant-drop command is a debug escape hatch: it POSTs debug/v1/tenant/{tenant_id}/drop and deletes all controller state for the tenant without doing a proper tenant deletion (no pageserver/remote-storage cleanup coordination). The --unclean flag is a mandatory confirmation; without it the command bails before making any request.

Source

Thrown at control_plane/storcon_cli/src/main.rs:939

                    .map(|s| {
                        (
                            s.tenant_shard_id,
                            preferred_az.clone().map(AvailabilityZone),
                        )
                    })
                    .collect(),
            };
            storcon_client
                .dispatch::<ShardsPreferredAzsRequest, ShardsPreferredAzsResponse>(
                    Method::PUT,
                    "control/v1/preferred_azs".to_string(),
                    Some(req),
                )
                .await?;
        }
        Command::TenantDrop { tenant_id, unclean } => {
            if !unclean {
                anyhow::bail!(
                    "This command is not a tenant deletion, and uncleanly drops all controller state for the tenant.  If you know what you're doing, add `--unclean` to proceed."
                )
            }
            storcon_client
                .dispatch::<(), ()>(
                    Method::POST,
                    format!("debug/v1/tenant/{tenant_id}/drop"),
                    None,
                )
                .await?;
        }
        Command::NodeDrop { node_id, unclean } => {
            if !unclean {
                anyhow::bail!(
                    "This command is not a clean node decommission, and uncleanly drops all controller state for the node, without checking if any tenants still refer to it.  If you know what you're doing, add `--unclean` to proceed."
                )
            }
            storcon_client

View on GitHub (pinned to 8f60b04da4)

Solutions

If you truly want to uncleanly drop controller state, re-run with --unclean
Prefer the regular tenant deletion flow when the tenant still exists end-to-end (pageserver, remote storage)
Clean up any orphaned pageserver/remote-storage data afterwards, since this path drops controller state only

Example fix

# before
storcon_cli tenant-drop --tenant-id <id>
# after
storcon_cli tenant-drop --tenant-id <id> --unclean

Defensive patterns

Strategy: validation

Prevention

Gate tenant-drop behind an explicit operator confirmation step in tooling
Prefer the standard tenant deletion API; reserve --unclean for broken controller state
After an unclean drop, schedule cleanup of orphaned pageserver and remote-storage data

When it happens

Trigger: Running storcon_cli tenant-drop without --unclean. The guard triggers purely on the missing flag, regardless of tenant state.

Common situations: Operators reaching for tenant-drop expecting a normal deletion workflow; leftover automation scripts from older versions that do not pass --unclean; using it on a tenant that is still live when a graceful deletion path (control-plane tenant deletion) should be used instead.

Related errors

AI-assisted analysis of neondatabase/neon@8f60b04da4 (2026-08-16). Data as JSON: /api/errors/6231c2c6677eb829. Report an issue: GitHub.