clockworklabs/SpacetimeDB · error

Unknown constraint type

Error message

Unknown constraint type

What it means

While validating a v9 module definition, the constraint validator only knows RawConstraintDataV9::Unique (crates/schema/src/def/validate/v9.rs:1332); every other variant of the (extensible) constraint data enum hits unimplemented!(). In practice this fires when the module's ABI contains a constraint kind this host build predates.

Source

Thrown at crates/schema/src/def/validate/v9.rs:1332

    {
        let RawConstraintDefV9 { name, data } = constraint;

        if let RawConstraintDataV9::Unique(RawUniqueConstraintDataV9 { columns }) = data {
            let name = make_name(name, &columns);

            let columns: Result<ColList> = self.validate_col_ids(&name, columns);
            let name = self.add_to_global_namespace(name);

            let (name, columns) = (name, columns).combine_errors()?;
            let columns: ColSet = columns.into();
            Ok(ConstraintDef {
                // Stamped by `ModuleDef::apply_namespace` once the module tree is assembled.
                namespace: NamespacePath::root(),
                name,
                data: ConstraintData::Unique(UniqueConstraintData { columns }),
            })
        } else {
            unimplemented!("Unknown constraint type")
        }
    }

    /// Validate a schedule definition.
    pub(crate) fn validate_schedule_def(
        &mut self,
        schedule: RawScheduleDefV9,
        primary_key: Option<ColId>,
    ) -> Result<ScheduleDef> {
        let RawScheduleDefV9 {
            // Despite the field name, a `RawScheduleDefV9` may refer to either a reducer or a function.
            reducer_name: function_name,
            scheduled_at_column,
            name,
        } = schedule;

        let name = name.unwrap_or_else(|| generate_schedule_name(&self.table_ident.clone()));

View on GitHub (pinned to 524b4487d9)

Solutions

1. Match versions: pin the module SDK to the version matching your host (compare with spacetime version / spacetimedb crate version)
2. Update the SpacetimeDB host (local spacetime start or the hosted cluster) to at least the SDK's version and republish
3. Until matched, declare only #[unique] constraints, which every current host validates

Example fix

# before (Cargo.toml)
spacetimedb = "2.0" # newer than host

# after
spacetimedb = "=1.x" # exact version supported by the running host

# Verify host and SDK agree before publishing:
spacetime version            # shows CLI/host version
grep -m1 'spacetimedb' Cargo.toml  # module SDK version
# Rule of thumb: SDK major.minor must be <= host major.minor

When it happens

Trigger: Publishing a module built with a newer spacetimedb SDK that emits a constraint kind other than unique (only 'unique' constraints are defined today) to an older host; hand-crafted ABI blobs with unknown constraint tags.

Common situations: SDK/host version skew after upgrading the Rust SDK but not the server; CI publishing with a pre-release toolchain against an older standalone host (spacetime start) or hosted cluster.

Related errors

• Unknown index algorithm {:?}
• unknown misc export
• Index '${indexLabel}' on table '${tableLabel}' must define a
• never types are not yet supported in C# output
• ERROR: Table '%s' not found when trying to add constraint to

AI-assisted analysis of clockworklabs/SpacetimeDB@524b4487d9 (2026-08-16). Data as JSON: /api/errors/98475ee6a6e97780. Report an issue: GitHub.