feat(sandbox): add test counter and SQLite load actors

[NathanFlurry]

Summary

• Add testCounter actor: simple in-memory state counter with increment/getCount/reset
• Add testCounterSqlite actor: same counter interface backed by SQLite via rivetkit/db
• Add testSqliteLoad actor: 50 migrations in onMigrate, runLoadTest action runs 20 diverse SQLite queries (inserts, selects, joins, aggregates, updates)

Test plan

• Verified all three actors work e2e locally via curl against the gateway API
• Confirm actors appear in sandbox inspector UI

🤖 Generated with Claude Code

[railway-app]

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

Service	Status	Web	Updated (UTC)
website	✅ Success (View Logs)	Web	Mar 25, 2026 at 4:05 am
kitchen-sink	❌ Build Failed (View Logs)	Web	Mar 25, 2026 at 4:02 am
frontend-inspector	😴 Sleeping (View Logs)	Web	Mar 24, 2026 at 9:12 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	Mar 24, 2026 at 9:05 pm
mcp-hub	✅ Success (View Logs)	Web	Mar 24, 2026 at 8:55 pm
ladle	❌ Build Failed (View Logs)	Web	Mar 24, 2026 at 8:54 pm

[claude]

PR Review: feat(sandbox): add test counter and SQLite load actors

Overall this is a clean, well-structured addition. The three actors follow RivetKit conventions consistently and demonstrate both in-memory and SQLite-backed state patterns nicely. A few things worth addressing:

---

Issues

test-sqlite-load.ts: schema_version table is misleading

The migration creates a table seeded with version = 50, but the version is not tracked incrementally. All 50 "migrations" always run together as a single onMigrate call, so this table is perpetually seeded to 50 rather than reflecting which migrations have actually been applied. Either remove the table (it provides no real tracking), or rename it to clarify its purpose. As-is, the schema version: 50 result in Query 19 may confuse readers into thinking migrations are individually versioned.

test-sqlite-load.ts: unsafe row access without null checks

Several places in runLoadTest access [0] on query results without checking for empty rows (Query 2: userId, Query 4: productId, Query 8: orderId). These are safe because the data was just inserted, but accessing [0] on an empty array yields undefined, and the type assertion hides it at compile time. If a future refactor reorders queries or an insert fails silently, this will produce a confusing runtime error. A comment like // safe: row was just inserted above would clarify intent; a runtime guard would be more robust.

test-sqlite-load.ts: no transaction wrapping in runLoadTest

The 20 queries run sequentially with no transaction. If the actor crashes mid-run the database is left in a partially inserted state. Wrapping the inserts in a transaction would make the test hermetic and also demonstrate SQLite transactional capability.

---

Minor

test-counter-sqlite.ts: two DB round-trips in increment

The increment action does an UPDATE followed by a SELECT to return the new value. If the bundled @rivetkit/sqlite supports it, UPDATE ... RETURNING value would eliminate the second round-trip (requires SQLite >= 3.35). If not supported, a comment noting this would help future maintainers.

---

What is working well

• Parameterized queries throughout — no SQL injection risk
• CREATE TABLE IF NOT EXISTS and CREATE INDEX IF NOT EXISTS everywhere — idempotent migrations
• testCounter vs testCounterSqlite is a great pairing to demonstrate in-memory vs. persistent state
• Good variety of SQLite operations in the load test (inserts, selects, joins, aggregates, GROUP BY, UPDATE)
• Clean imports and registry additions in index.ts following existing patterns
• Actor definitions are minimal and readable