SpacetimeDB daemon panics and crashes on updating a module re-creating the same index

[egormanga]

Setup:

#[table(name=user)]
struct User {
	#[primary_key]
	id: Identity,

	#[unique]
	username: String,
}

#[table(name=thing)]
struct Thing {
	#[primary_key]
	#[auto_inc]
	id: u64,

	#[index(btree)]
	owner: Identity,
}

Logs:

INFO crates/core/src/db/update.rs:143: Creating index `thing_owner_idx_btree` on table `thing`
thread 'tokio-runtime-worker' panicked at crates/table/src/table.rs:1790:14:
called `Option::unwrap()` on a `None` value

stack backtrace:

stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: core::option::unwrap_failed
   4: spacetimedb_table::table::UniqueConstraintViolation::build
   5: spacetimedb::db::datastore::locking_tx_datastore::mut_tx::MutTxId::create_index::{{closure}}
   6: spacetimedb::db::datastore::locking_tx_datastore::mut_tx::MutTxId::create_index
   7: spacetimedb::db::update::update_database
   8: <spacetimedb::host::wasm_common::module_host_actor::WasmModuleInstance<T> as spacetimedb::host::module_host::ModuleInstance>::update_database
   9: <spacetimedb::host::module_host::AutoReplacingModuleInstance<T> as spacetimedb::host::module_host::ModuleInstance>::update_database
  10: spacetimedb::host::module_host::ModuleHost::call::{{closure}}::{{closure}}
  11: tokio::runtime::task::core::Core<T,S>::poll
  12: tokio::runtime::task::harness::Harness<T,S>::poll
  13: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  14: tokio::runtime::scheduler::multi_thread::worker::Context::run
  15: tokio::runtime::context::scoped::Scoped<T>::set
  16: tokio::runtime::context::runtime::enter_runtime
  17: tokio::runtime::scheduler::multi_thread::worker::run
  18: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
  19: tokio::runtime::task::core::Core<T,S>::poll
  20: tokio::runtime::task::harness::Harness<T,S>::poll
  21: tokio::runtime::blocking::pool::Inner::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Steps to reproduce:

1. Publish a module as specified above;
2. Create two thing table entries with the same owner value;
3. Comment out the index annotation on the owner field;
4. Publish (update) the module;
5. Uncomment the annotation back;
6. Try to publish the module again.

At this point, the whole database process crashes with a panic.

Removing either User or the unique annotation in it fixes the problem.

Speculation:

Apparently, the index (or its contents, somehow) doesn't get fully deleted when it should, causing a collision on subsequent creation.
Or, maybe, it's being mistakingly implicitly treated as unique for some reason (leaked state in the macro from above in User?).

Perhaps, related to #1525?

[bfops]

Thank you for reporting this! We'll look into it.

[bfops]

Here's the full module I used to repro:

use spacetimedb::{ReducerContext, Table, Identity, table, reducer};

#[table(name=user)]
struct User {
	#[primary_key]
	id: Identity,

	#[unique]
	username: String,
}

#[table(name=thing)]
struct Thing {
	#[primary_key]
	#[auto_inc]
	id: u64,

	#[index(btree)]
	owner: Identity,
}

#[reducer]
pub fn add(ctx: &ReducerContext, owner: Identity) {
    ctx.db.thing().insert(Thing { id: 0, owner });
}

@egormanga at least on 1.2.0, my database process doesn't crash. It does emit a panic but it stays up and accepts further publishes, etc. Is that the behavior that you see?

[Centril]

@bfops I couldn't reproduce a panic on master, but I do get:

Error: Failed to create or update the database: DatastoreError: IndexError: Unique constraint violation 't_b_idx_btree' in table 't': column(s): '["b"]' value: 42

which is incorrect, using the following simplified version:

use spacetimedb::{reducer, table, ReducerContext, Table};

#[table(name = p)]
struct P {
    #[unique]
    x: u64,

    #[unique]
    y: u64,
}

#[table(name = t)]
#[derive(Copy, Clone)]
struct T {
    a: u64,

    #[index(btree)]
    b: u64,
}

#[reducer]
pub fn setup(ctx: &ReducerContext) {
    ctx.db.t().insert(T { a: 0, b: 42 });
    ctx.db.t().insert(T { a: 1, b: 42 });
}

It seems clear that P is somehow affecting T. I'll investigate why.

[Centril]

Simplified further:

use spacetimedb::{reducer, table, ReducerContext, Table};

#[table(name = p)]
struct P {
    #[unique]
    x: u64,

    #[unique]
    y: u64,
}

#[table(name = t)]
#[derive(Copy, Clone)]
struct T {
    a: u64,
    b: u64,
}

#[reducer]
pub fn setup(ctx: &ReducerContext) {
    ctx.db.t().insert(T { a: 0, b: 42 });
    ctx.db.t().insert(T { a: 1, b: 42 });
}

To reproduce:

spacetime start --in-memory &
spacetime publish repro-2761 -c -y
spacetime call repro-2761 setup
# Add `#[index(btree)]` to field `b`.
spacetime publish repro-2761

I've found a fix. :)