What causes "system tables cannot have schedules, but table {}: {sch:?}" in clockworklabs/SpacetimeDB?

Remove the schedule from the system table schema.

system tables cannot have schedules, but table {}: {sch:?}

Error message

system tables cannot have schedules, but table {}: {sch:?}

What it means

While normalizing system table schemas, any attached schedule is rejected with a panic: system tables must not have scheduled reducers, and id assignment for system-table schedules is deliberately not implemented (the comment below notes IDs would need to be set if this ever changed). This runs during system schema definition at startup or in tests. It is an internal guard for core development, not a user-facing validation.

Source

Thrown at crates/datastore/src/system_tables.rs:855

                    constraint.constraint_name, result.table_name
                )
            });
    }
    for sequence in &mut result.sequences {
        sequence.sequence_id = SEQUENCE_IDS
            .get(&sequence.sequence_name[..])
            .copied()
            .unwrap_or_else(|| {
                panic!(
                    "missing system table sequence id for sequence {} of table {}",
                    sequence.sequence_name, result.table_name
                )
            });
        sequence.start = ST_RESERVED_SEQUENCE_RANGE as i128 + 1;
        // sequence.allocated = ST_RESERVED_SEQUENCE_RANGE as i128;
    }
    if let Some(sch) = result.schedule {
        panic!(
            "system tables cannot have schedules, but table {}: {sch:?}",
            result.table_name
        );
    }
    result.normalize();
    // Note, if we ever added system tables with schedules, we would need to set their IDs here too.
    result
}

fn st_table_schema() -> TableSchema {
    st_schema(ST_TABLE_NAME, ST_TABLE_ID)
}

fn st_column_schema() -> TableSchema {
    st_schema(ST_COLUMN_NAME, ST_COLUMN_ID)
}

fn st_index_schema() -> TableSchema {

View on GitHub (pinned to 6dee26c6ef)

Solutions

Remove the schedule from the system table schema.
If schedules on system tables are genuinely needed, implement schedule id assignment for them and remove the guard, per the comment below the panic.
Keep the system-table test suite green when touching system_tables.rs.

Defensive patterns

Strategy: try-catch

Validate before calling

// core devs: reject schedules on system tables at definition time
type TableSchema = (); // placeholder
fn assert_no_schedule(schema: &TableSchema) {
    // if TableSchema exposes `schedule`, fail fast with a clear message here
}

Try / catch

let r = std::panic::catch_unwind(build_system_tables);
if r.is_err() {
    // a system table carries a schedule: remove it from the schema definition
}

Prevention

Keep schedules out of system table definitions by convention.
Extend the system-table tests to assert schedule is None for every system table.
Review the note in system_tables.rs when adding scheduling features.

When it happens

Trigger: Defining a system table schema that includes a schedule; panics in the normalizer when result.schedule is Some during construction of that schema.

Common situations: Core development adding scheduled reducers; forks copying user-table patterns into system tables; rebases that move schedules into system table definitions.

Related errors

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