fix(rivetkit): wire CancellationToken through waitForNamesAvailable to eliminate KV busy-polling

[abcxff]

Fixes RVT-6297

[railway-app]

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

Service	Status	Web	Updated (UTC)
kitchen-sink	❌ Build Failed (View Logs)	Web	May 22, 2026 at 5:08 am
frontend-cloud	😴 Sleeping (View Logs)	Web	May 21, 2026 at 10:58 pm
website	😴 Sleeping (View Logs)	Web	May 21, 2026 at 10:33 am
frontend-inspector	❌ Build Failed (View Logs)	Web	May 19, 2026 at 8:20 pm
mcp-hub	✅ Success (View Logs)	Web	May 18, 2026 at 5:01 pm
ladle	✅ Success (View Logs)	Web	May 18, 2026 at 5:01 pm

[abcxff]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(rivetkit): wire CancellationToken through waitForNamesAvailable to eliminate KV busy-polling #5063 : 2 dependent PRs (#5050 , #5089 ) 👈 (View in Graphite)
• fix(rivetkit): fix BigInt serialization in inspector workflow history and state deserialization #5058
• WIP: counter latency monitor #5093
• main

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

[linear]

RVT-6297

[claude]

PR Review: fix(rivetkit): wire CancellationToken through waitForNamesAvailable to eliminate KV busy-polling

Summary

This PR replaces a busy-polling loop in waitForNamesAvailable with a properly wired CancellationToken, bringing it into parity with the other queue wait methods (waitForNames, next, nextBatch, enqueueAndWait). The old approach sliced timeouts into 100 ms windows and restarted the call in a loop — a pattern explicitly forbidden by CLAUDE.md ("If it is inside a loop { check; sleep } body, it is polling and should be event-driven instead"). The new approach is correctly event-driven.

Overall this is a good, well-scoped fix. There are two type-safety issues worth addressing.

---

Bug: NapiCoreRuntime.actorQueueWaitForNamesAvailable omits the asNativeCancellationToken cast

File: rivetkit-typescript/packages/rivetkit/src/registry/napi-runtime.ts, line 684

Every other signal-bearing queue method in NapiCoreRuntime wraps the signal via asNativeCancellationToken() before passing it to the NAPI layer:

// actorQueueNextBatch
signal ? asNativeCancellationToken(signal) : signal,

// actorQueueWaitForNames
signal ? asNativeCancellationToken(signal) : signal,

// actorQueueEnqueueAndWait
signal ? asNativeCancellationToken(signal) : signal,

But the new actorQueueWaitForNamesAvailable passes signal directly without the cast. This breaks the established invariant that the NAPI-facing Queue.waitForNamesAvailable receives a typed NativeCancellationToken, not an opaque CancellationTokenHandle. If the handle representation ever diverges from the NAPI type, this silently passes the wrong object.

Fix:

.waitForNamesAvailable(names, options, signal ? asNativeCancellationToken(signal) : signal);

---

Consistency: WasmCoreRuntime.actorQueueWaitForNamesAvailable also omits asWasmCancellationToken

File: rivetkit-typescript/packages/rivetkit/src/registry/wasm-runtime.ts, line 770

Same pattern issue on the wasm side. All other signal-bearing wasm queue calls cast the signal explicitly via asWasmCancellationToken(), but the new waitForNamesAvailable passes signal bare to callHandleAsync. Since callHandleAsync calls .apply(handle, args) as-is, there is no implicit cast.

Fix:

await callHandleAsync(queue, "waitForNamesAvailable", names, options, signal ? asWasmCancellationToken(signal) : signal);

---

Code Quality: Good

• The deletion of the polling loop (~53 lines) is the main win. The new CancellationToken-based approach is event-driven and consistent with all sibling methods.
• The try/finally { cleanup?.() } pattern correctly handles the case where cleanup is undefined (no signal provided, or signal already aborted before listener registration).
• createCancellationTokenHandle correctly cancels immediately when signal.aborted is already true, preserving the pre-existing "check aborted first" behavior.
• The CoreRuntime interface is correctly updated to include the signal parameter.
• The Rust core side (queue_wait_opts in queue.rs) was already wired to forward CancellationToken into QueueWaitOpts.signal — this PR correctly completes the end-to-end wiring.

---

Test Coverage Gap

There are no tests for waitForNamesAvailable with an AbortSignal. The existing actor-queue.test.ts covers signal abort for next and iter but not for waitForNamesAvailable. Since the core purpose of this PR is correct signal propagation, a test that aborts mid-wait and asserts the correct error is thrown would prevent regression. Not a blocker, but worth a follow-up.

---

CLAUDE.md Compliance

• No println!/eprintln! — clean.
• No Mutex<HashMap> — not applicable.
• No inline #[cfg(test)] blocks — clean.
• No _ => fall-through in enum matches — not applicable.
• Conventional commit message format — correct.
• Change correctly scoped to TS/NAPI layer; actor lifecycle logic remains in rivetkit-core.

---

Required Changes

1. napi-runtime.ts: Add asNativeCancellationToken() cast when passing signal to waitForNamesAvailable.
2. wasm-runtime.ts: Add asWasmCancellationToken() cast for the same reason.

[abcxff]

Merge activity

• May 19, 8:06 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 19, 8:08 PM UTC: The Graphite merge of this pull request was cancelled.