What causes "token info must be present after token creation by name" in influxdata/influxdb?

Check for concurrent token deletion/rename races and serialize token-management operations.

token info must be present after token creation by name

Error message

token info must be present after token creation by name

What it means

A `.expect(...)` panic right after enterprise token creation: the code writes the token, then re-reads it by name from the token repo and asserts it exists. If the read returns None, the write and subsequent read are inconsistent — an internal invariant failure (concurrent delete, name collision handling, or write not committed).

Solutions

Check for concurrent token deletion/rename races and serialize token-management operations.
Verify the name used at creation matches the name used in `get_by_name` exactly (case, whitespace, encoding).
Re-run the operation; if reproducible single-threaded, it is a library bug — report it with the token name and catalog version.
Replace the `expect` with an error return (e.g. internal error) so callers get a recoverable failure instead of a panic.

Defensive patterns

Strategy: retry

Try / catch

// panic, not catchable as an error; wrap the whole creation in catch_unwind and retry once
let res = std::panic::catch_unwind(|| create_token_with_permission(...));
if res.is_err() { retry_with_backoff_or_report_bug(); }

Prevention

Serialize token create/delete/rename operations (single writer or lock) to avoid read-back races.
Use plain ASCII token names without whitespace or case tricks.
After any panic here, verify catalog state for partially created tokens before retrying.
Report reproducible single-threaded failures to InfluxData — this is an internal invariant.

When it happens

Trigger: Calling `create_token_with_permission` when the just-created token cannot be found by name on the immediate `get_by_name` lookup — e.g. another thread deleted/renamed it between the write and the read, or the write silently failed to insert under the expected name.

Common situations: Concurrent token management (one thread creating while another lists/deletes tokens); a bug in the write path (wrong name stored); unusual token names (empty, unicode) that don't round-trip through `get_by_name`.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19). Data as JSON: /api/errors/ec9a441bd44f8ce6. Report an issue: GitHub.

Appendix: source

Thrown at influxdb3_catalog/src/catalog/versions/v1/enterprise.rs:118

                        token_id,
                        name: Arc::from(token_name.as_str()),
                        hash: hash.clone(),
                        created_at,
                        expiry,
                        permissions: all_perms,
                    },
                )],
            }))
        })
        .await?;

        let token_info = {
            self.inner
                .read()
                .tokens
                .repo()
                .get_by_name(&token_name)
                .expect("token info must be present after token creation by name")
        };

        // we need to pass these details back, especially this token as this is what user should
        // send in subsequent requests
        Ok((token_info, token))
    }
}

impl InnerCatalog {
    pub fn apply_token_batch_enterprise(&mut self, token_batch: &TokenBatch) -> Result<bool> {
        let mut is_updated = false;
        for op in &token_batch.ops {
            is_updated |= match op {
                TokenCatalogOp::CreateAdminToken(create_admin_token_details) => {
                    // add an entry into permissions
                    self.token_permissions.add_permission(
                        ResourceType::Wildcard,
                        TokenPermissionResourceIdentifier::Wildcard,

View on GitHub (pinned to 06200ef96b)