influxdata/influxdb · error

token creation to return full token info

Error message

token creation to return full token info

What it means

When running `influxdb3 create token --admin --regenerate` (after typing 'yes' at the confirmation prompt), the CLI POSTs to /api/v3/configure/token/admin/regenerate and the client returns Result<Option<CreateTokenWithPermissionsResponse>>. The .expect panics when the server answered successfully but the body was missing or did not contain full token info, i.e. the Option came back None. It means the endpoint replied without the JSON token payload the CLI requires — most often because --host points at the wrong endpoint or the server is an older version.

Source

Thrown at influxdb3/src/commands/create/token.rs:96

            created_at: chrono::Utc::now().timestamp_millis(),
            updated_at: None,
            updated_by: None,
            expiry_millis: i64::MAX,
            permissions: vec![], // Admin tokens don't need explicit permissions
        });

        CreateTokenWithPermissionsResponse::from_token_info(token_info, token)
            .ok_or_else(|| "Failed to create token response".into())
    } else {
        let json_body = if config.regenerate {
            println!("Are you sure you want to regenerate admin token? Enter 'yes' to confirm",);
            let mut confirmation = String::new();
            io::stdin().read_line(&mut confirmation)?;
            if confirmation.trim() == "yes" {
                client
                    .api_v3_configure_regenerate_admin_token()
                    .await?
                    .expect("token creation to return full token info")
            } else {
                return Err("Cannot regenerate token without confirmation".into());
            }
        } else {
            client
                .api_v3_configure_create_admin_token()
                .await?
                .expect("token creation to return full token info")
        };
        Ok(json_body)
    }
}

fn generate_offline_token() -> String {
    create_token_and_hash().0
}

pub(crate) async fn handle_named_admin_token_creation(

View on GitHub (pinned to d28e26e048)

Solutions

  1. Point --host at the admin token recovery endpoint: influxdb3 create token --admin --regenerate --host http://<recovery-bind-address> (the address given to --admin-token-recovery-http-bind on the server).
  2. Verify the CLI and server are the same InfluxDB 3 version — older servers return a reduced/no body for the regenerate endpoint.
  3. Reproduce with curl -X POST against the chosen --host and confirm the response is a JSON body with token info; if a proxy returns an empty 200, bypass or fix it.
  4. If it persists on matched versions, report it: the CLI should turn the None into an error message instead of .expect (compare the offline branch which uses ok_or_else).

Example fix

# before
influxdb3 create token --admin --regenerate --host http://127.0.0.1:8181
# -> panic: token creation to return full token info

# after: target the admin token recovery endpoint
influxdb3 create token --admin --regenerate \
  --host http://127.0.0.1:8182   # the --admin-token-recovery-http-bind address
Defensive patterns

Strategy: validation

Validate before calling

// If calling the client directly, handle the None instead of expect:
match client.api_v3_configure_regenerate_admin_token().await? {
    Some(resp) => Ok(resp),
    None => Err("server returned no token info; is --host the admin-token-recovery endpoint?".into()),
}

Prevention

When it happens

Trigger: Running `influxdb3 create token --admin --regenerate` where the request succeeds (2xx) but the response body is empty or not the full token JSON: pointing --host at the main server instead of the admin-token-recovery endpoint (the flag help says regeneration needs --host set to the address configured via --admin-token-recovery-http-bind), a CLI/server version mismatch where the endpoint returns a different shape, or a proxy returning 200 with an empty body.

Common situations: Regenerating the operator token after it was lost, while the recovery endpoint is on a different port and --host still defaults to http://127.0.0.1:8181; mixing an influxdb3 CLI from one release with a server binary from another; a load balancer or sidecar intercepting the POST and returning an empty 200.

Related errors


AI-assisted analysis of influxdata/influxdb@d28e26e048 (2026-08-16). Data as JSON: /api/errors/093d7f1e037bf138. Report an issue: GitHub.