clockworklabs/SpacetimeDB · error

AddSequence: sequence `{sequence_name}` not found in new mod

Error message

AddSequence: sequence `{sequence_name}` not found in new module def

What it means

AddSequence resolved the storing table, but plan.new.lookup::<SequenceDef>(key) returned None: the sequence is not registered as a lookupable entity in the new module def set although the table references it. The def set's entity registry and table-level sequence references are inconsistent (namespace-key drift for submodules, or mismatched macro versions). The publish aborts.

Source

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

                    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)?;
            }
            spacetimedb_schema::auto_migrate::AutoMigrateStep::AddSequence(key) => {
                let (namespace, sequence_name) = key;
                let (owning_def, table_def) = plan
                    .new
                    .find_storing_table(namespace, sequence_name)
                    .ok_or_else(|| anyhow::anyhow!("AddSequence: `{sequence_name}` not found in new module def"))?;
                let table_full_name = joined(namespace, &table_def.name);
                let sequence_def: &SequenceDef = plan.new.lookup(key).ok_or_else(|| {
                    anyhow::anyhow!("AddSequence: sequence `{sequence_name}` not found in new module def")
                })?;
                let table_id = stdb.table_id_from_name_mut(tx, &table_full_name)?.unwrap();
                let table_schema = stdb.schema_for_table_mut(tx, table_id)?;

                log!(logger, "Adding sequence `{sequence_name}` to table `{table_full_name}`");
                let mut sequence_schema =
                    SequenceSchema::from_module_def(owning_def, sequence_def, table_schema.table_id, 0.into());

                // Apply namespace prefix for submodule sequences
                sequence_schema.sequence_name = namespace.join_raw(&sequence_schema.sequence_name);
                stdb.create_sequence(tx, sequence_schema)?;
            }
            spacetimedb_schema::auto_migrate::AutoMigrateStep::RemoveSequence(key) => {
                let (namespace, sequence_name) = key;
                let (_owning_def, table_def) = plan
                    .old
                    .find_storing_table(namespace, sequence_name)
                    .ok_or_else(|| anyhow::anyhow!("RemoveSequence: `{sequence_name}` not found in old module def"))?;

View on GitHub (pinned to 6dee26c6ef)

Solutions

1. Full clean rebuild (delete target/ entirely), spacetime build, republish.
2. Add the sequence while the table sits at the crate root; move it into the submodule in a later publish.
3. Verify a single SDK version in the tree: cargo tree -i spacetimedb.
4. Dev: spacetime publish --delete-data <db>.
5. Report as a def-indexing bug with the submodule layout.

Example fix

// before: auto_inc on a submodule table; registry lookup misses
mod guild {
    #[spacetimedb::table(name = "members")]
    pub struct Member { #[auto_inc] pub id: u64 }
}

// after: add the sequence at the root first
#[spacetimedb::table(name = "members")]
pub struct Member { #[auto_inc] pub id: u64 }

use spacetimedb_schema::auto_migrate::AutoMigrateStep;
use spacetimedb_schema::def::SequenceDef;
for step in &plan.steps {
    if let AutoMigrateStep::AddSequence(key) = step {
        anyhow::ensure!(
            plan.new.lookup::<SequenceDef>(key).is_some(),
            "sequence {:?} missing from the new def registry", key
        );
    }
}

fn sequence_registered(plan: &AutoMigratePlan, key: (&str, &str)) -> bool {
    plan.new.lookup::<SequenceDef>(key).is_some()
}

match update_database(&stdb, tx, &plan, ...).await {
    Err(e) if e.to_string().contains("AddSequence: sequence") => {
        // Def registry desync: full clean rebuild; add the sequence at a stable module path.
    }
    result => result?,
}

When it happens

Trigger: Sequences on tables inside submodules whose registration namespace differs from the table's; defs produced by two different SDK macro versions so the table's sequence map and the registry disagree.

Common situations: Auto-increment columns on submodule tables; upgrading the SDK between builds; incremental builds mixing artifacts from two toolchains.

Related errors

• AddConstraint: constraint `{constraint_name}` not found in n
• AddSequence: `{sequence_name}` not found in new module def
• RemoveSequence: `{sequence_name}` not found in old module de
• Precheck: sequence `{sequence_name}` not found in new module
• Precheck failed: added sequence {sequence_name} refers to un

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