influxdata/influxdb · error · ProtoV1AnyWithStorageError

Error converting partition_template

Error message

Error converting partition_template: {0}

What it means

ProtoV1AnyWithStorageError::PartitionTemplate is raised when the partition_template field of a proto v1 NamespaceWithStorage/TableWithStorage fails ValidationError during conversion into the native PartitionTemplate type — the stored partitioning spec is structurally or semantically invalid.

Solutions

  1. Fix the partition_template in the stored proto so it passes ValidationError rules (valid parts, existing columns)
  2. Recreate the namespace/table with a valid partition template
  3. Check for version mismatches between the writer and reader of the proto

Example fix

// before (proto template)
parts: [{type: PARTITION_BY_UNKNOWN_COLUMN, column: "gone"}]
// after
parts: [{type: PARTITION_BY_STRING, column: "region"}] // valid existing column
Defensive patterns

Strategy: validation

Validate before calling

fn partition_template_valid(t: &PartitionTemplateProto) -> bool {
    !t.parts.is_empty() && t.parts.iter().all(|p| p.column_is_known() && p.r#type_is_supported())
}

Try / catch

let ns = NamespaceWithStorage::try_from(proto).map_err(|e| match e {
    ProtoV1AnyWithStorageError::PartitionTemplate(src) => anyhow!("invalid partition template: {}", src),
    other => anyhow!(other),
})?;

Prevention

When it happens

Trigger: Converting a v1 proto whose partition_template violates validation rules (bad partition types, invalid column references, malformed template parts).

Common situations: Partition templates written by other tooling or versions with unsupported parts; users configuring invalid partitioning that was persisted and now fails on read; schema changes removing columns referenced by a stored template.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors


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

Appendix: source

Thrown at core/data_types/src/lib.rs:480

            deleted_at: value.deleted_at.map(google::Timestamp::from),
        }
    }
}

/// Errors converting from a catalog_storage proto v1 NamespaceWithStorage or TableWithStorage to
/// [`NamespaceWithStorage`] or [`TableWithStorage`].
#[derive(Debug, Error)]
pub enum ProtoV1AnyWithStorageError {
    /// invalid value for MaxTables
    #[error("Error converting max_tables: {0}")]
    MaxTables(ServiceLimitError),

    /// invalid value for MaxColumnsPerTable
    #[error("Error converting max_columns_per_table: {0}")]
    MaxColumnsPerTable(ServiceLimitError),

    /// invalid value for PartitionTemplate
    #[error("Error converting partition_template: {0}")]
    PartitionTemplate(ValidationError),
}

impl TryFrom<catalog_storage_proto::NamespaceWithStorage> for NamespaceWithStorage {
    type Error = ProtoV1AnyWithStorageError;

    /// We require fallible conversion because generated protobuf structs can carry any i32
    /// value for `max_tables` and `max_columns_per_table`, which is larger than the domain
    /// `MaxTables` and `MaxColumnsPerTable` can represent (i.e. 0..=i32::MAX).
    /// The `partition_template` can also be invalid.
    fn try_from(value: catalog_storage_proto::NamespaceWithStorage) -> Result<Self, Self::Error> {
        let max_tables =
            MaxTables::try_from(value.max_tables).map_err(ProtoV1AnyWithStorageError::MaxTables)?;
        let max_columns_per_table = MaxColumnsPerTable::try_from(value.max_columns_per_table)
            .map_err(ProtoV1AnyWithStorageError::MaxColumnsPerTable)?;
        let partition_template = value
            .partition_template
            .map(TryInto::try_into)

View on GitHub (pinned to 06200ef96b)