clockworklabs/SpacetimeDB · critical

{CALL_VIEW_DUNDER} export is a function with incorrect type:

Error message

{CALL_VIEW_DUNDER} export is a function with incorrect type: {err}

What it means

The `__call_view__` export is a function, but `TypedFunc::typed` rejects it because its parameters/results do not match `CallViewType`, so the host panics. This indicates the view entry ABI (query/view id, sender and argument encoding, return encoding) differs from what this server build expects. Like the other dunder-export panics, it is a module/host version mismatch rather than a bug in the view query itself.

Source

Thrown at crates/core/src/host/wasmtime/wasmtime_module.rs:471

        export
            .into_func()
            .unwrap_or_else(|| panic!("{CALL_PROCEDURE_DUNDER} export is not a function"))
            .typed(store)
            .unwrap_or_else(|err| panic!("{CALL_PROCEDURE_DUNDER} export is a function with incorrect type: {err}")),
    )
}

/// Look up the `instance`'s export named by [`CALL_VIEW_DUNDER`].
///
/// Similar to [`get_call_procedure`], but for views.
fn get_call_view(store: &mut Store<WasmInstanceEnv>, instance: &Instance) -> Option<CallViewType> {
    let export = instance.get_export(store.as_context_mut(), CALL_VIEW_DUNDER)?;
    Some(
        export
            .into_func()
            .unwrap_or_else(|| panic!("{CALL_VIEW_DUNDER} export is not a function"))
            .typed(store)
            .unwrap_or_else(|err| panic!("{CALL_VIEW_DUNDER} export is a function with incorrect type: {err}")),
    )
}

/// Look up the `instance`'s export named by [`CALL_VIEW_ANON_DUNDER`].
///
/// Similar to [`get_call_procedure`], but for anonymous views.
fn get_call_view_anon(store: &mut Store<WasmInstanceEnv>, instance: &Instance) -> Option<CallViewAnonType> {
    let export = instance.get_export(store.as_context_mut(), CALL_VIEW_ANON_DUNDER)?;
    Some(
        export
            .into_func()
            .unwrap_or_else(|| panic!("{CALL_VIEW_ANON_DUNDER} export is not a function"))
            .typed(store)
            .unwrap_or_else(|err| panic!("{CALL_VIEW_ANON_DUNDER} export is a function with incorrect type: {err}")),
    )
}

/// Look up the `instance`'s export named by [`CALL_HTTP_HANDLER_DUNDER`].

View on GitHub (pinned to 6dee26c6ef)

Solutions

  1. Rebuild and republish the module with the SDK/CLI matching the server version.
  2. Diff the export signature with `wasm2wat module.wasm | grep -A5 __call_view__` against a module freshly generated by the current SDK.
  3. Clear build caches (target/, CI cache) so an old artifact cannot be republished.
  4. Check the spacetimedb changelog for view-ABI changes between your module's SDK and the server.
Defensive patterns

Strategy: type-guard

Validate before calling

use wasmtime::{Engine, Module, ExternType};

fn view_export_well_formed(engine: &Engine, wasm: &[u8]) -> Result<(), String> {
    let module = Module::new(engine, wasm).map_err(|e| e.to_string())?;
    if let Some(exp) = module.get_export("__call_view__") {
        if !matches!(exp.ty(), ExternType::Func(func_ty) if func_ty.params().len() > 0) {
            return Err("__call_view__ must be a function with the server's view ABI".into());
        }
    }
    Ok(())
}

Type guard

fn is_func_export(ty: &ExternType) -> bool { matches!(ty, ExternType::Func(_)) }

Try / catch

if std::panic::catch_unwind(instantiate).is_err() {
    // check the panic message for "__call_view__" and rebuild the module against the matching SDK
}

Prevention

When it happens

Trigger: Publishing or instantiating a module whose `__call_view__` function signature differs from the TypedFunc signature the running server binds (e.g. extra/missing params after an SDK upgrade changed the view calling convention).

Common situations: Server upgraded while the module artifact was built by an older SDK; modules built in CI with a cached toolchain; SDK releases that changed the view entry signature.

Related errors


AI-assisted analysis of clockworklabs/SpacetimeDB@6dee26c6ef (2026-08-20). Data as JSON: /api/errors/be3bce99067c8e25. Report an issue: GitHub.