clockworklabs/SpacetimeDB · error · WasmError

Error resolving row type for view

Error message

Error resolving row type for view

What it means

The wasmtime-side twin of the module_host_actor check: after a view call returns during refresh, the view's product_type_ref is resolved against the owning module's typespace and converted into a product type. Failure means the reference does not resolve to a row/product type in that typespace — the module's type definitions and the view definition disagree.

Source

Thrown at crates/core/src/host/wasmtime/wasm_instance_env.rs:1804

                            "failed to look up materialized view args for view {}",
                            view_call.view_id
                        )
                    })?
                    .sender();

                let current_tx = tx.take().expect("procedure tx missing during view refresh");
                let (next_tx, call_result) = tx_slot.set(current_tx, || {
                    Self::call_view(caller, &view_call, view_name, fn_ptr, sender)
                });
                tx = Some(next_tx);
                let return_data = call_result?;

                let typespace = resolved.owning_def.typespace();
                let row_product_type = typespace
                    .resolve(view_def.product_type_ref)
                    .resolve_refs()?
                    .into_product()
                    .map_err(|_| anyhow!("Error resolving row type for view"))?;

                let rows = match ViewResult::from_return_data(return_data)? {
                    ViewResult::Rows(bytes) => deserialize_view_rows(view_def.product_type_ref, bytes, typespace)
                        .map_err(|err| anyhow!(err.to_string()))?,
                    ViewResult::RawSql(query) => run_query_for_view(
                        tx.as_mut().expect("procedure tx missing while running view query"),
                        &query,
                        &row_product_type,
                        &view_call,
                        *caller.data().instance_env.database_identity(),
                    )?,
                };

                let stdb = caller.data().instance_env.relational_db().clone();
                stdb.materialize_view_call(
                    tx.as_mut()
                        .expect("procedure tx missing while materializing refreshed view"),
                    table_id,

View on GitHub (pinned to 524b4487d9)

Solutions

1. Rebuild and republish with SDK and host versions in lockstep so view metadata and typespace come from the same build.
2. Clear stale view state (drop the views or recreate the database if disposable) and republish.
3. Verify via module introspection that each view's row type resolves in its owning module's typespace.
4. If it reproduces on a clean build, report it with the module artifact.

// verify the view row type resolves in the owning module's typespace before refresh
let ty = owning_def.typespace().resolve(view_def.product_type_ref)?.resolve_refs()?;
ty.into_product()?;

When it happens

Trigger: product_type_ref points at a type that is not in the resolved typespace or is not a product: a module built against a different SDK/typespace than the one that recorded the view definition, stale view metadata after upgrades, or corrupted module artifacts.

Common situations: SDK/host version skew across republishes; moving views between modules or submodules; partial upgrades leaving old view metadata in place.

Related errors

• Error resolving row type for view
• cannot serialize refs without a typespace
• cannot deserialize refs without a typespace
• view {:?} does not have a backing table
• view `{}` for view id `{}` not found in current module

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