clockworklabs/SpacetimeDB · error

unexpected error from `datastore_delete_by_index_scan_range_

Error message

unexpected error from `datastore_delete_by_index_scan_range_bsatn`: {e}

What it means

Raised inside a SpacetimeDB reducer when the `datastore_delete_by_index_scan_range_bsatn` host syscall returns an errno the bindings do not consider possible for a ranged index delete. The bindings call `RangedIndex::delete(range)` (e.g. `ctx.db.user().dogs_and_name().delete(25u64..)`), encode the range args, and panic on any non-OK status. In practice this means the module and the database host disagree about the index or the module binary is talking to an incompatible host, not that your range logic is wrong.

Source

Thrown at crates/bindings/src/table.rs:967

    /// though at present no such constraints exist.
    pub fn delete<B, K>(&self, b: B) -> u64
    where
        B: IndexScanRangeBounds<IndexType, K>,
    {
        let index_id = Idx::index_id();
        if const { is_point_scan::<Idx, B, _, _>() } {
            b.with_point_arg(|point| {
                sys::datastore_delete_by_index_scan_point_bsatn(index_id, point)
                    .unwrap_or_else(|e| {
                        panic!("unexpected error from `datastore_delete_by_index_scan_point_bsatn`: {e}")
                    })
                    .into()
            })
        } else {
            let args = b.get_range_args();
            let (prefix, prefix_elems, rstart, rend) = args.args_for_syscall();
            sys::datastore_delete_by_index_scan_range_bsatn(index_id, prefix, prefix_elems, rstart, rend)
                .unwrap_or_else(|e| panic!("unexpected error from `datastore_delete_by_index_scan_range_bsatn`: {e}"))
                .into()
        }
    }
}

/// Performs a ranged scan using the range arguments `B` in `Tbl` using `Idx`.
///
/// The type parameter `K` is either `()` or [`SingleBound`]
/// and is used to workaround the orphan rule.
fn filter<Tbl, Idx, IndexType, B, K>(b: B) -> impl Iterator<Item = Tbl::Row>
where
    Tbl: Table,
    Idx: Index,
    B: IndexScanRangeBounds<IndexType, K>,
{
    let index_id = Idx::index_id();

    let iter = if const { is_point_scan::<Idx, B, _, _>() } {

View on GitHub (pinned to 6dee26c6ef)

Solutions

1. Republish the module so the wasm binary and the database schema/indexes are rebuilt together: `spacetime publish <db> --clear-data` (or a fresh database) to rule out schema drift.
2. Align versions: make the `spacetimedb-bindings` version in your module's Cargo.toml match the server/CLI version you deploy against.
3. Reproduce with a minimal reducer that only performs the ranged delete to confirm the range arguments themselves are well-formed.
4. If it persists with matching versions, capture the `{e}` errno in the panic message and report it as a SpacetimeDB issue — this panic marks a host invariant violation.

// Reducer: wrap the ranged delete so an unexpected host error is logged,
// then deliberately abort the transaction (panic = rollback in SpacetimeDB).
let result = std::panic::catch_unwind(|| {
    ctx.db.user().dogs_and_name().delete(25u64..)
});
if let Err(panic) = result {
    log::error!("ranged delete failed: {panic:?}");
    panic!(); // or convert into a reducer error path
}

When it happens

Trigger: Calling `RangedIndex::delete` with a non-point range (e.g. `25u64..`, `(25u64, "J".."K")`) when the host returns an unexpected errno: publishing a module whose index definitions no longer match the live database schema, mixing an older `spacetimedb-bindings` crate with a newer server, or a host-internal error while scanning/deleting rows.

Common situations: Version skew between the spacetimedb toolchain (`spacetime publish`) and the bindings crate pinned in Cargo.toml; republishing after changing an index's columns without a clean publish; CI builds that reuse a stale module against a migrated database.

Related errors

• unexpected error from `datastore_index_scan_range_bsatn`: {e
• unexpected insertion error: {e}
• unexpected update error: {e}
• Someone put a forbidden variant in the system table!
• When replaying `st_column` update: `table_primary_key` shoul

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