influxdata/influxdb · critical · CatalogError
record id exceeds the cluster's committed feature level…
Error message
record id {record_id} exceeds the cluster's committed feature level (core={}, enterprise={}); the cluster must finish upgrading before this operation is available What it means
Thrown when a catalog record (WAL/log entry) carries a record id larger than the feature level the cluster has committed to. This means a node tried to write or apply an operation the cluster has not agreed to support yet, indicating an incomplete or inconsistent upgrade.
Solutions
- Finish the cluster upgrade so all nodes run the target version and the committed feature level advances.
- Verify all node binaries are the same version (no downgraded nodes remain).
- Re-run the feature-level commit/upgrade step after all nodes report readiness.
- Restore from a backup taken before the mixed-version writes if the log is corrupted.
Example fix
// before // mixed-version writes proceed silently // after let committed = catalog.committed_feature_level(); assert!(local_level <= committed, "node ahead of committed level; complete upgrade first");
Defensive patterns
Strategy: try-catch
Validate before calling
if record.record_id() > committed.max_record_id() {
return Err("record exceeds committed feature level; finish upgrade".into());
} Try / catch
match result {
Err(CatalogError::RecordExceedsCommittedFeatureLevel { committed, .. }) => {
log::error!("mixed-version writes detected; committed={committed:?}");
}
other => other?,
} Prevention
- Never run mixed-version clusters longer than the upgrade window
- Complete feature-level commit after all nodes upgrade
- Block downgrades once the level has advanced
When it happens
Trigger: A node with a newer binary writes records beyond the committed FeatureLevel; replaying WAL/catalog segments written by a newer version against an older committed level; enterprise/core level mismatch during rolling upgrades.
Common situations: Rolling upgrade interrupted midway; downgrading a node then restarting against a newer catalog log; mixed-version clusters where one node is ahead of the committed level.
Understand the failure class
Background: "is not a compatible type" / "cannot merge" errors: when a value's type doesn't match what the library requires — this error's family across 65 libraries.
Related errors
- this node's feature level
- {0}
- Adding a new database would exceed limit of
- attempted to create a resource that already exists
- attempted to modify resource that was already deleted
AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19).
Data as JSON: /api/errors/75f529c0fc0b29db.
Report an issue: GitHub.
Appendix: source
Thrown at influxdb3_catalog/src/error.rs:345
CannotDeleteOperatorToken,
#[error(
"cannot change the configured generation duration for level {level}; \
attempted to set to {attempted:#} but its already set to {existing:#}"
)]
CannotChangeGenerationDuration {
level: u8,
existing: Duration,
attempted: Duration,
},
#[error("cannot add column {name} because it already exists with type {existing}")]
DuplicateColumn {
name: Arc<str>,
existing: InfluxColumnType,
},
#[error(
"record id {record_id} exceeds the cluster's committed feature level (core={}, enterprise={}); \
the cluster must finish upgrading before this operation is available",
committed.core,
committed.enterprise,
)]
RecordExceedsCommittedFeatureLevel {
record_id: u16,
committed: FeatureLevel,
},
#[error(
"this node's feature level (core={}, enterprise={}) is below the cluster's committed level (core={}, enterprise={}); upgrade required",
local.core,
local.enterprise,
committed.core,
committed.enterprise,
)]
NodeBelowCommittedFeatureLevel {View on GitHub (pinned to 06200ef96b)