clockworklabs/SpacetimeDB · error

AddConstraint: `{constraint_name}` not found in new module d

Error message

AddConstraint: `{constraint_name}` not found in new module def

What it means

Applying AddConstraint: the diff plans creating a constraint, but no table in the new module def reports storing it (plan.new.find_storing_table returns None). The constraint key in the step does not resolve in the new defs - the plan and the module definition set are inconsistent. The publish aborts before the constraint is created.

Source

Thrown at crates/engine/src/update.rs:479

                let constraint_schema = table_schema
                    .constraints
                    .iter()
                    .find(|constraint| constraint.constraint_name == stored_name)
                    .unwrap();

                log!(
                    logger,
                    "Dropping constraint `{constraint_name}` on table `{table_full_name}`"
                );
                stdb.drop_constraint(tx, constraint_schema.constraint_id)?;
            }
            spacetimedb_schema::auto_migrate::AutoMigrateStep::AddConstraint(key) => {
                let (namespace, constraint_name) = key;
                let (owning_def, table_def) = plan
                    .new
                    .find_storing_table(namespace, constraint_name)
                    .ok_or_else(|| anyhow::anyhow!("AddConstraint: `{constraint_name}` not found in new module def"))?;
                let table_full_name = joined(namespace, &table_def.name);
                let constraint_def: &ConstraintDef = plan.new.lookup(key).ok_or_else(|| {
                    anyhow::anyhow!("AddConstraint: constraint `{constraint_name}` not found in new module def")
                })?;
                let table_id = stdb
                    .table_id_from_name_mut(tx, &table_full_name)?
                    .expect("table should exist in the database for AddConstraint");
                let mut constraint_schema =
                    ConstraintSchema::from_module_def(owning_def, constraint_def, table_id, ConstraintId::SENTINEL);

                // Apply namespace prefix for submodule constraints
                constraint_schema.constraint_name = namespace.join_raw(&constraint_schema.constraint_name);
                log!(
                    logger,
                    "Adding constraint `{constraint_name}` on table `{table_full_name}`"
                );
                stdb.create_constraint(tx, constraint_schema)?;
            }

View on GitHub (pinned to 6dee26c6ef)

Solutions

1. Clean-rebuild and republish.
2. Add the constraint in its own publish with no other schema edits.
3. Keep the owning table's name and location stable (pin with #[table(name = "...")]).
4. Align SDK/CLI/server versions across all machines and CI publishing the database.
5. Dev: spacetime publish --delete-data <db>.
6. File an issue with the plan if a clean single-change publish still fails.

Example fix

// before: add #[unique] while moving the table to a submodule in one publish
mod guild {
    #[spacetimedb::table(name = "members")]
    pub struct Member { #[unique] pub name: String }
}

// after: two publishes
// 1) add the constraint on the unmoved table
#[spacetimedb::table(name = "players")]
pub struct Player { #[unique] pub name: String }
// 2) move the table separately

use spacetimedb_schema::auto_migrate::AutoMigrateStep;
for step in &plan.steps {
    if let AutoMigrateStep::AddConstraint((namespace, cname)) = step {
        if plan.new.find_storing_table(namespace, cname).is_none() {
            anyhow::bail!("new def lacks storing table for constraint {}", cname);
        }
    }
}

fn constraint_stores_in_new_def(plan: &AutoMigratePlan, ns: &str, cname: &str) -> bool {
    plan.new.find_storing_table(ns, cname).is_some()
}

match update_database(&stdb, tx, &plan, ...).await {
    Err(e) if e.to_string().contains("AddConstraint")
        && e.to_string().contains("not found in new module def") => {
        // Split publishes: add the constraint with the table unchanged, refactor later.
    }
    result => result?,
}

When it happens

Trigger: Adding #[unique]/constraint attributes while also renaming or moving the table or the constrained columns in the same publish; constraint-name normalization or namespace-prefix differences between the def the planner diffed and the def being applied.

Common situations: Adding a unique constraint during a broader table refactor; submodule moves of newly-constrained tables; SDK version changes between build and publish.

Related errors

• RemoveConstraint: `{constraint_name}` not found in old modul
• ChangeTableAccessorName: `{table_name}` not found in new mod
• ChangeColumnAccessorName: `{table_name}` not found in new mo
• Column `{col_name}` not found in table `{table_name}`
• ChangeIndexSourceName: `{index_name}` not found in old modul

AI-assisted analysis of clockworklabs/SpacetimeDB@6dee26c6ef (2026-08-20). Data as JSON: /api/errors/a4996298cacf658e. Report an issue: GitHub.