feat(inspector): insert and clear actor queue

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• feat(inspector): insert and clear actor queue #5343 kxkuwlls · 2026-06-26 19:41:40 👈
• main

Get stack: forklift get 5343
Push local edits: forklift submit
Merge when ready: forklift merge 5343

[claude]

This PR adds two new inspector HTTP endpoints for the actor queue: DELETE /inspector/queue (clear/reset the queue) and POST /inspector/queue (enqueue a message). The implementation is cleanly wired across the Rust core, NAPI bindings, and both TypeScript runtime adapters (native and WASM). All four issues flagged in my previous review have been addressed in the current revision.

Fixes confirmed in current diff:

• queue_notify.notify_waiters() is now called after the reset, waking parked consumers.
• queue_metadata lock is held across the entire reset operation, eliminating the concurrent-enqueue race.
• next_id is preserved across reset rather than zeroed, preventing stale CompletionHandle instances from corrupting the new ID-1 message.
• message.id().toString() is used in native.ts instead of Number(message.id()), avoiding bigint truncation.

---

Three smaller issues remain:

Partial-failure leaves KV metadata stale on restart

If batch_delete succeeds but the subsequent kv.put(&QUEUE_METADATA_KEY, ...) fails, the in-memory metadata.size is already set to 0 (line runs before the put) and the lock is released on Err. KV messages are gone, but the persisted metadata still shows the pre-reset size. On the next actor cold-start the engine will reload the stale metadata, temporarily reporting a wrong queue depth. This self-corrects on the next full list scan, but the window exists.

Empty name is accepted without validation

InspectorEnqueueBody uses #[serde(default)] on name: String, and the TS handler does body.name ?? "". If the caller omits name, the message is silently enqueued with an empty string. Whether that is intentional or a bug depends on whether other queue paths enforce a non-empty name. If they do, both the Rust and TS paths should return a 400 instead.

No test coverage

The new reset() method has no tests. In particular, the interaction with a consumer parked in next_batch() (that it wakes and returns empty) and the concurrent-enqueue-during-reset path (that the lock serializes it correctly) are exactly the cases that matter but are hard to verify by inspection alone. Even a single integration test that resets a queue mid-consumer would meaningfully increase confidence.

[railway-app]

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

Service	Status	Web	Updated (UTC)
frontend-cloud	😴 Sleeping (View Logs)	Web	Jun 26, 2026 at 8:09 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Jun 26, 2026 at 8:09 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Jun 26, 2026 at 8:09 pm
website	😴 Sleeping (View Logs)	Web	Jun 26, 2026 at 7:51 pm
ladle	✅ Success (View Logs)	Web	Jun 26, 2026 at 7:44 pm
mcp-hub	✅ Success (View Logs)	Web	Jun 26, 2026 at 7:42 pm