clockworklabs/SpacetimeDB · error · Exception

While table `{RemoteTableName}` was applying: {deltaString}

Error message

While table `{RemoteTableName}` was applying:
{deltaString} 
to:
{entriesString}

What it means

Thrown by the C# client SDK while merging a server subscription delta into the table's local row cache. The inner exception comes from MultiDictionary.Apply (e.g. an 'Attempted to apply ... resulted in a multiplicity of N' failure, meaning the delta assumes different row counts than the client currently holds) or from row deserialization. The message embeds the first 10,000 characters of the incoming delta and of the current cache contents so you can diff what the server sent against local state; the original exception is preserved as InnerException.

Source

Thrown at sdks/csharp/src/Table.cs:495

                    foreach (var row in delta.EventRows)
                    {
                        wasInserted.Add(new KeyValuePair<object, Row>(row, row));
                    }
                }
                return;
            }

            try
            {
                Entries.Apply(delta.Delta, wasInserted, wasUpdated, wasRemoved);
            }
            catch (Exception e)
            {
                var deltaString = parsedTableUpdate.ToString();
                deltaString = deltaString[..Math.Min(deltaString.Length, 10_000)];
                var entriesString = Entries.ToString();
                entriesString = entriesString[..Math.Min(entriesString.Length, 10_000)];
                throw new Exception($"While table `{RemoteTableName}` was applying:\n{deltaString} \nto:\n{entriesString}", e);
            }

            // Update indices.
            // This is a local operation -- it only looks at our indices and doesn't invoke user code.
            // So we don't need to wait for other tables to be updated to do it.
            // (And we need to do it before any PostApply is called.)
            // Reminder: We need to loop through the removed entries to delete them prior to inserting the new entries,
            // in order to avoid keys an error with the same key already added.
            foreach (var (_, value) in wasRemoved)
            {
                OnInternalDeleteHandler.Invoke(value);
            }
            foreach (var (_, value) in wasInserted)
            {
                OnInternalInsertHandler.Invoke(value);
            }
            foreach (var (_, oldValue, newValue) in wasUpdated)
            {

View on GitHub (pinned to fdd647dfac)

Solutions

Inspect the InnerException and the dumped delta vs entries strings to identify which table row key/multiplicity disagrees.
Regenerate C# bindings (spacetime generate) against the currently deployed module and align the SpacetimeDB SDK NuGet version with the server version.
Ensure only one active subscription covers a given table at a time: unsubscribe fully before re-subscribing to the same table.
If the cache is corrupt, recreate the DbConnection/DbView so the cache is rebuilt from a fresh SubscriptionApplied snapshot.

Example fix

// before: overlapping subscriptions on the same table
var sub1 = conn.Db.Player.OnInsert(p => ...);
var subs = conn.SubscriptionBuilder()
    .OnApplied(() => ...)
    .Subscribe("SELECT * FROM Player");
// ...later another .Subscribe("SELECT * FROM Player") while cache is mid-update

// after: one subscription per table, unsubscribe before changing scope
await subs.UnsubscribeAsync();
var subs2 = conn.SubscriptionBuilder()
    .OnError(e => Log.Error($"apply failed: {e.InnerException?.Message}"))
    .Subscribe("SELECT * FROM Player");

Defensive patterns

Strategy: try-catch

Try / catch

conn.SubscriptionBuilder()
    .OnError(ex => {
        var root = ex.InnerException ?? ex;
        Log.Error($"Table apply failed: {root.Message}"); // message contains delta/cache dump
        // recover: unsubscribe and resubscribe to rebuild the cache
    })
    .Subscribe("SELECT * FROM Player");

Prevention

Regenerate C# bindings after every module schema change and keep the SDK NuGet version aligned with the server.
Maintain at most one active subscription per table; fully unsubscribe before re-subscribing with a different query.
Never hand-edit generated table classes.

When it happens

Trigger: Processing a subscription update for this table where the delta's inserts/deletes disagree with the client's cache: overlapping subscriptions on the same table where one is unsubscribed mid-stream, applying updates after a dropped/re-created subscription, or client row types that no longer match the redeployed module schema (added/removed columns).

Common situations: Module redeployed (schema changed) while the client keeps bindings generated by the old CLI; toggling subscriptions on the same table at runtime; reconnecting after a server restart with stale local cache rows; SDK NuGet package version drifted from the spacetimedb server version.

Related errors

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