clockworklabs/SpacetimeDB · error · DBError::Other

no such module

Error message

no such module

What it means

Thrown by ModuleHost::call_sql_command when the call_instance! dispatch cannot find a live module instance to run `call_sql` on; any dispatch failure is collapsed into DBError::Other("no such module"). The host keeps one instantiated module per database, so this means no module instance is currently running for that database: it was never published, failed to start, crashed, or is mid-replacement during an update. It is a lifecycle error, not a SQL error: the statement never reached an executor.

Source

Thrown at crates/core/src/host/module_host.rs:2065

    pub(in crate::host) fn record_view_command_round_trip(info: &ModuleInfo, metric: ViewCommandMetric) {
        match metric.workload {
            WorkloadType::Subscribe => info
                .metrics
                .request_round_trip_subscribe
                .observe(metric.timer.elapsed().as_secs_f64()),
            WorkloadType::Unsubscribe => info
                .metrics
                .request_round_trip_unsubscribe
                .observe(metric.timer.elapsed().as_secs_f64()),
            _ => {}
        }
    }

    async fn call_sql_command(&self, cmd: SqlCommand) -> Result<SqlCommandResult, DBError> {
        call_instance!(self, "call_sql", cmd, |cmd, inst| inst.call_sql(cmd), |cmd, inst| inst
            .call_sql(cmd)
            .await,)
        .map_err(|_| DBError::Other(anyhow::anyhow!("no such module")))
    }

    pub async fn disconnect_client(&self, client_id: ClientActorId) {
        log::trace!("disconnecting client {client_id}");
        if let Err(e) = call_instance!(
            self,
            "disconnect_client",
            client_id,
            |client_id, inst| inst.disconnect_client(client_id),
            |client_id, inst| inst.disconnect_client(client_id).await,
        ) {
            log::error!("Error from client_disconnected transaction: {e}");
        }
    }

    pub fn disconnect_client_inner(
        client_id: ClientActorId,
        info: &ModuleInfo,

View on GitHub (pinned to 524b4487d9)

Solutions

  1. Verify the module is actually running: check publish output and host logs for the database address and successful module startup.
  2. Wait for module readiness (poll a trivial call or the host's module info) and retry the SQL command.
  3. If startup failed, inspect module logs, fix the startup error, and republish.
  4. Confirm the database address/identity used by the caller matches the one the module was published to.

Example fix

// before: fire SQL right after publish
publish(module).await;
host.call_sql_command(cmd).await?; // "no such module"

// after: gate on module readiness first
publish(module).await;
wait_for_module_running(&host, database_address).await?;
host.call_sql_command(cmd).await?;
Defensive patterns

Strategy: retry

Validate before calling

// Gate SQL traffic on module readiness instead of racing instance startup.
// Poll the host module-info endpoint (or a trivial subscription) until running:
while !client.module_info(address).await?.is_running {
    tokio::time::sleep(Duration::from_millis(100)).await;
}

Try / catch

match host.call_sql_command(cmd).await {
    Err(e @ DBError::Other(_)) if e.to_string().contains("no such module") => {
        // instance not up (yet) — wait for readiness and retry with backoff
        retry_with_backoff(|| host.call_sql_command(cmd.clone())).await
    }
    other => other,
}

Prevention

When it happens

Trigger: Calling call_sql against a database whose instance is absent: (1) no module published at that address; (2) publish finished but instance startup is still in flight; (3) the instance died (panic/trap) and a replacement has not registered; (4) a database update temporarily removed the old instance before the new one is up.

Common situations: Scripts issuing SQL immediately after publish without waiting for module startup; clients pointed at the wrong database address; deploying a module that compiles but fails at startup so the instance never registers; host/module version skew after an upgrade.

Related errors


AI-assisted analysis of clockworklabs/SpacetimeDB@524b4487d9 (2026-08-16). Data as JSON: /api/errors/2e1649da77cd1c34. Report an issue: GitHub.