clockworklabs/SpacetimeDB · critical · RangeError

unknown reducerId ${reducerId}

Error message

unknown reducerId ${reducerId}

What it means

When the host invokes a reducer, the module runtime maps the numeric reducerId from the wire onto the flattened list of reducer functions across the root module and all submodules. If the id falls outside every submodule's range (>= total reducer count), dispatch throws RangeError('unknown reducerId <n>'): the host and the deployed module disagree about the reducer table.

Source

Thrown at crates/bindings-typescript/src/server/runtime.ts:577

    if (reducerId < this.#consumerReducerCount) {
      fn = this.#schema.reducers[reducerId];
      dbView = this.#dbView;
      asViews = this.#consumerAs;
    } else {
      let offset = this.#consumerReducerCount;
      for (let i = 0; i < this.#flatSubmodules.length; i++) {
        const m = this.#flatSubmodules[i];
        if (reducerId < offset + m.reducerFns.length) {
          fn = m.reducerFns[reducerId - offset];
          dbView = this.#getSubmoduleDbView(i);
          asViews = this.#getSubmoduleAsViews(i);
          break;
        }
        offset += m.reducerFns.length;
      }
      if (fn === undefined) {
        throw new RangeError(`unknown reducerId ${reducerId}`);
      }
    }

    const ctx = this.#reducerCtx;
    ReducerCtxImpl.reset(
      ctx,
      senderIdentity,
      new Timestamp(timestamp),
      ConnectionId.nullIfZero(new ConnectionId(connId)),
      dbView!,
      asViews!
    );
    callUserFunction(fn, ctx, args);
  }

  __call_view__(
    id: u32,
    sender: u256,

View on GitHub (pinned to 524b4487d9)

Solutions

  1. Redeploy the module and reconnect clients so reducer ids are regenerated consistently
  2. Regenerate client bindings against the currently deployed module (spacetime generate)
  3. Treat reducer signatures as append-only between deploys: add new reducers instead of reordering or removing old ones
  4. If it persists, restart the host to clear stale dispatch state and report the module hash plus host version
Defensive patterns

Strategy: validation

Prevention

When it happens

Trigger: The dispatching host was built against a different module schema: the module was redeployed with reducers removed or reordered while an in-flight call or stale host state references old ids; submodule sets differing between builds of the same module.

Common situations: Redeploying a module with reordered/removed reducers while old bindings or host caches persist; version skew between the spacetimedb host, the hosttools that generated code, and the deployed module; partial or failed deploys.

Related errors


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