influxdata/influxdb · error · EnterpriseCatalogError

Node doesn't have proper mode, expect

Error message

Node doesn't have proper mode, expect {expected}

What it means

EnterpriseCatalogError::InvalidNodeMode, a thiserror catalog error in the Enterprise edition. It is returned when a node's configured NodeMode does not match the mode required by the operation being performed (e.g. calling an operation that expects a specific all/compat/compactor role). It carries the `expected` NodeMode so the caller knows which mode was required.

Solutions

1. Restart the node with the required mode: `influxdb3 serve --node-mode <expected>`.
2. Check the node's current mode in the catalog (`show nodes` or the node definition) and compare to the operation's requirement.
3. Update deployment scripts/systemd units/ Helm charts so each node's --node-mode matches its intended role.
4. Route role-restricted operations to a node that has the expected mode.

Example fix

// before
influxdb3 serve --node-mode query  # then runs compaction ops
// after
influxdb3 serve --node-mode all    # or route compaction to a compactor-mode node

// shell: check node mode before running role-restricted ops
current_mode=$(influxdb3 show nodes | jq -r '.[] | select(.id==ENV.NODE_ID) | .mode');
[ "$current_mode" = "all" ] || echo "node must run in required mode"

// Rust caller
match catalog_result {
    Err(EnterpriseCatalogError::InvalidNodeMode { expected }) => {
        eprintln!("restart node with --node-mode {:?}", expected);
    }
    other => other?,
}

When it happens

Trigger: Calling an Enterprise catalog operation gated on a node role — e.g. issuing catalog reads/writes reserved for a particular NodeMode from a node started with a different --node-mode (all, write, query, compactor).

Common situations: Starting a node with a restrictive mode and then running operations meant for an `all` node; cluster topology changes where a node was repurposed but its mode flag was not updated; copying one node's config to another.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

• Current node mode does not use the processing engine
• each subsequent generation must be an even multiple of its…
• gen2 duration must be an even multiple of gen1 duration…
• invalid configuration provided
• {0}

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

Appendix: source

Thrown at influxdb3_catalog/src/error/enterprise.rs:31

            NodeMode::Core => "core",
            NodeMode::Query => "query",
            NodeMode::Ingest => "ingest",
            NodeMode::Compact => "compact",
            NodeMode::Process => "process",
            NodeMode::All => "all",
        }
    }
}

impl std::fmt::Display for NodeMode {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "{}", self.as_str())
    }
}

#[derive(Debug, thiserror::Error, Clone, Copy)]
pub enum EnterpriseCatalogError {
    #[error("Node doesn't have proper mode, expect {expected}")]
    InvalidNodeMode { expected: NodeMode },

    #[error(
        "too many compacted generations requested, maximum allowed: 254, requested: {requested}"
    )]
    TooManyCompactedGenerations { requested: usize },

    #[error("gen1 duration is not configured in the catalog")]
    MissingGen1Duration,

    #[error(
        "gen2 duration must be an even multiple of gen1 duration, \
        provided gen2 duration: {gen2_duration_secs} seconds, \
        existing gen1 duration: {gen1_duration_secs} seconds"
    )]
    InvalidGen2Duration {
        gen2_duration_secs: u64,
        gen1_duration_secs: u64,

View on GitHub (pinned to 06200ef96b)