fix(rivetkit-core): chunk apply_batch puts/deletes at 128

[abcxff]

copy of https://app.graphite.com/github/pr/rivet-dev/rivet/5012

[railway-app]

🚅 Deployed to the rivet-pr-5046 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
kitchen-sink	❌ Build Failed (View Logs)	Web	May 13, 2026 at 6:44 pm
website	😴 Sleeping (View Logs)	Web	May 13, 2026 at 9:30 am
frontend-cloud	❌ Build Failed (View Logs)	Web	May 12, 2026 at 12:51 pm
frontend-inspector	❌ Build Failed (View Logs)	Web	May 12, 2026 at 12:51 pm
ladle	❌ Build Failed (View Logs)	Web	May 12, 2026 at 12:51 pm
mcp-hub	✅ Success (View Logs)	Web	May 12, 2026 at 12:50 pm

[abcxff]

• [slop]fix(workflow-engine): only commit step state after success #5010 : 2 dependent PRs (#5048 , #5052 )
• fix(rivetkit): decode bridge errors with actor: null #5056
• fix(rivetkit): bind methods through createWriteThroughProxy #4987
• feat(rivetkit): add ConnectionMap readonly Map wrapper for actor connections #5047
• fix(rivetkit-core): chunk apply_batch puts/deletes at 128 #5046 👈 (View in Graphite)
• fix(pegboard): validate drain_grace_period < request_lifespan #4998
• chore(rivetkit): log inspector errors + standardize pino errorKey error #4986
• fix(rivetkit): remove async drizzle db proxy #4984 : 2 other dependent PRs (#4985 , #4991 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

PR Review: fix(rivetkit-core): chunk apply_batch puts/deletes at 128

Overview

This PR fixes a bug where persist_state could send more than 128 keys in a single apply_batch call, violating the engine-side MAX_KEYS = 128 limit enforced in engine/packages/pegboard/src/actor_kv/utils.rs. The fix chunks puts and deletes into 128-item slices and issues multiple sequential apply_batch calls.

Correctness

The chunking logic is correct. Looking at apply_batch in kv.rs, puts and deletes are already sent as separate batch_put / batch_delete RPC calls, so the 128-key limit applies to each list independently. The loop handles mismatched list lengths correctly: when one iterator is exhausted, unwrap_or returns an empty slice and the remaining chunks of the other list continue to be drained.

Issues

1. Missing test for the >128 key path

The existing test_apply_batch_call_count assertions in task.rs (lines ~1980, ~1998) all use small key counts well under 128, so they do not exercise the new code path. A test with 129+ ConnHibernation deltas in a single save_state call would confirm chunking works end-to-end and guard against regressions.

2. Payload size limit not addressed

The engine also enforces MAX_PUT_PAYLOAD_SIZE = 976 KiB per validate_entries. With 128 entries each near the 128 KiB per-value ceiling, a single chunk could still exceed this. For current use cases (connection hibernation data is small) this is unlikely to trigger, but worth noting as a latent failure mode.

3. Non-atomicity of chunked writes (acknowledged)

The TODO comment correctly describes the risk: a failure mid-loop leaves actor state partially persisted. The SQLite migration path in the TODO is the right long-term fix. No action needed now beyond the existing comment.

Minor Notes

• Doc comment on APPLY_BATCH_CHUNK_SIZE correctly mirrors the engine constant and explains why it exists.
• pub(crate) visibility is appropriate.
• Comment style is consistent with CLAUDE.md conventions.

Summary

The fix is logically correct and the non-atomicity trade-off is properly called out. The main gap is test coverage: recommend adding a test that saves more than 128 ConnHibernation deltas in a single save_state call and verifies all entries are persisted.

[abcxff]

Merge activity

• May 13, 6:35 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 13, 6:44 PM UTC: Graphite rebased this pull request as part of a merge.
• May 13, 6:44 PM UTC: @abcxff merged this pull request with Graphite.