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
- Redeploy the module and reconnect clients so reducer ids are regenerated consistently
- Regenerate client bindings against the currently deployed module (spacetime generate)
- Treat reducer signatures as append-only between deploys: add new reducers instead of reordering or removing old ones
- If it persists, restart the host to clear stale dispatch state and report the module hash plus host version
Defensive patterns
Strategy: validation
Prevention
- Treat reducer signatures as append-only: add new reducers, never reorder or remove, between deploys
- Regenerate bindings (spacetime generate) after every module schema change and reconnect clients
- Pin host, hosttools, and SDK versions together and verify the deployed module hash after each deploy
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
- unknown viewId ${id}
- unknown anonViewId ${id}
- unknown procedureId ${id}
- cannot serialize refs without a typespace
- cannot deserialize refs without a typespace
AI-assisted analysis of clockworklabs/SpacetimeDB@524b4487d9 (2026-08-16).
Data as JSON: /api/errors/1fc838f2d3277088.
Report an issue: GitHub.