What causes "view {} not found in database" in clockworklabs/SpacetimeDB?

Re-run the publish so the update path recreates view registrations consistent with module_def.

view {} not found in database

Error message

view {} not found in database

What it means

Mirror image of the module_def lookup: the module defines the view and the global function pointer was found, but tx.view_from_name cannot find a matching st_view row in the database. The module code and the database's view catalog are out of sync — the module expects a registered view the database never created or no longer has.

Source

Thrown at crates/core/src/host/wasm_common/module_host_actor.rs:1534

    for (prefix, owning_def, view) in module_def.all_views_with_prefix() {
        let ViewDef {
            name: local_name,
            is_anonymous,
            product_type_ref,
            ..
        } = view;

        // Full namespaced canonical name: matches both the st_view registration
        // (create_view / create_view_with_prefix) and `view_by_name_with_global_fn_ptr`.
        let view_name = prefix.join(local_name.clone());

        let (global_fn_ptr, _, _) = module_def
            .view_by_name_with_global_fn_ptr(&view_name)
            .ok_or_else(|| anyhow::anyhow!("view {} not found in module_def", view_name))?;

        let st_view = tx
            .view_from_name(&view_name)?
            .ok_or_else(|| anyhow::anyhow!("view {} not found in database", view_name))?;

        let view_id = st_view.view_id;
        let table_id = st_view
            .table_id
            .ok_or_else(|| anyhow::anyhow!("view {} does not have a backing table in database", view_name))?;
        let subs = tx.materialized_view_instances_for_view(view_id);
        let view_typespace = Arc::new(owning_def.typespace().clone());

        if *is_anonymous {
            if subs.is_empty() {
                continue;
            }
            view_calls.push(CallViewParams {
                view_name: view_name.clone(),
                view_id,
                table_id,
                fn_ptr: global_fn_ptr,
                caller: owner_identity,

View on GitHub (pinned to 524b4487d9)

Solutions

Re-run the publish so the update path recreates view registrations consistent with module_def.
If the catalog is stuck inconsistent, recreate the database (when data is disposable) or repair the st_view rows.
Verify the canonical view name matches exactly, including prefixes, between module and database.
Let publishes commit or roll back fully; avoid killing them midway.

Defensive patterns

Strategy: validation

Validate before calling

// verify the database catalog contains every view the module defines
for name in module_def.view_names() {
    anyhow::ensure!(tx.view_from_name(name)?.is_some(), "view {name} missing from database");
}

Prevention

Let publishes commit or roll back fully; never kill them midway.
After an interrupted publish, republish to reconcile the view catalog.
Avoid out-of-band restores or edits of system tables.

When it happens

Trigger: View registration rows were never created for this database (a publish interrupted before view registration committed) or were removed; publishing a module whose view set differs from the database catalog without going through the normal update path; databases restored or modified out-of-band.

Common situations: Interrupted or partially failed publishes; database backups restored mid-update; direct manipulation of system tables.

Related errors

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