clockworklabs/SpacetimeDB · error · UpdateDatabaseResult::ErrorExecutingMigration

Views evaluation did not complete successfully during databa

Error message

Views evaluation did not complete successfully during database update: {:?}

What it means

Companion to the trap case: after evaluating subscribed views during a database update, the host checks the outcome; anything other than ViewOutcome::Success that did not trap is formatted into this message with the outcome's debug value. The transaction is rolled back and the publish fails as ErrorExecutingMigration, so the database remains on its previous schema and data.

Source

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

                };
                let durable_offset = stdb.durable_tx_offset();

                let res: UpdateDatabaseResult = match res {
                    crate::db::update::UpdateResult::Success => {
                        let tx_offset = succeed(self.info.clone(), FunctionBudget::ZERO, Duration::ZERO, tx);
                        UpdateDatabaseResult::UpdatePerformed {
                            tx_offset,
                            durable_offset,
                        }
                    }
                    crate::db::update::UpdateResult::EvaluateSubscribedViews => {
                        let (out, _, trapped) = self.evaluate_subscribed_views(tx, inst)?;
                        tx = out.tx;
                        if trapped || out.outcome != ViewOutcome::Success {
                            let msg = match trapped {
                                true => "Trapped while evaluating views during database update".to_string(),
                                false => format!(
                                    "Views evaluation did not complete successfully during database update: {:?}",
                                    out.outcome
                                ),
                            };

                            let (_, tx_metrics, reducer) = stdb.rollback_mut_tx(tx);
                            stdb.report_mut_tx_metrics(reducer, tx_metrics, None);
                            UpdateDatabaseResult::ErrorExecutingMigration(anyhow::anyhow!(msg))
                        } else {
                            let tx_offset =
                                succeed(self.info.clone(), out.execution_budget_used, out.total_duration, tx);
                            UpdateDatabaseResult::UpdatePerformed {
                                tx_offset,
                                durable_offset,
                            }
                        }
                    }
                    crate::db::update::UpdateResult::RequiresClientDisconnect => {
                        let tx_offset = succeed(self.info.clone(), FunctionBudget::ZERO, Duration::ZERO, tx);

View on GitHub (pinned to 524b4487d9)

Solutions

  1. Read the embedded outcome value — budget exhaustion points at expensive views; other outcomes point at the runner's specific reason.
  2. Optimize or narrow the views (filters, limits, incremental logic) so evaluation completes within budget.
  3. Raise the execution budget for the update if the deployment allows it.
  4. Re-run the publish once the views fit the budget; the failed attempt rolled back cleanly.
Defensive patterns

Strategy: try-catch

Validate before calling

// Size-check views before an update: evaluate them against a production-sized copy
// and confirm they finish within the configured execution budget.
let elapsed = time_evaluate_all_views(snapshot_db.clone())?;
anyhow::ensure!(elapsed < view_budget(), "views exceed budget: {elapsed:?}");

Try / catch

match update_result {
    UpdateDatabaseResult::ErrorExecutingMigration(e)
        if e.to_string().contains("did not complete successfully") =>
    {
        // read the embedded outcome; narrow the views or raise the budget, then republish
        log::warn!("update rejected: {e:#}");
    }
    other => { /* ... */ }
}

Prevention

When it happens

Trigger: View evaluation during a publish ends abnormally without a trap: execution budget or time limits exhausted by expensive views over large tables, or an internal non-success outcome reported by the view runner (embedded in the message as the {:?} value).

Common situations: Materialized views scanning very large tables during migration on a loaded host; unbounded view computations; execution budget defaults too small for the dataset size.

Related errors

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