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 21, 2026 at 12:35 am
frontend-cloud	😴 Sleeping (View Logs)	Web	May 19, 2026 at 8:27 pm
frontend-inspector	❌ Build Failed (View Logs)	Web	May 19, 2026 at 8:20 pm
website	😴 Sleeping (View Logs)	Web	May 18, 2026 at 5:13 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 , #5065 ) 👈 (View in Graphite)
• fix(rivetkit): fix BigInt serialization in inspector workflow history and state deserialization #5058
• fix(workflow-engine): only commit step state after success #5010 : 1 other dependent PR (#5052 )
• fix(rivetkit): bind methods through createWriteThroughProxy #4987
• fix(rivetkit): remove client-side connection request size check #5057
• main

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

[linear]

RVT-6297

[claude]

PR Review: Wire CancellationToken through waitForNamesAvailable

Summary: This PR (RVT-6297) replaces a busy-polling loop in waitForNamesAvailable with native CancellationToken propagation, removing ~44 lines of polling boilerplate in favor of 7 lines that reuse the existing createCancellationTokenHandle pattern.

---

What's Good

Correct use of existing patterns. The PR adopts the same createCancellationTokenHandle + finally { cleanup?.() } idiom already used by enqueueAndWait and other queue operations. This is the right approach per the CLAUDE.md constraint against reintroducing polling loops or BigInt token registries.

Interface consistency. Adding the optional signal parameter to CoreRuntime, NapiCoreRuntime, and WasmCoreRuntime together keeps all three runtime implementations in sync, which is the expected pattern.

Net code reduction. The old polling logic had subtle edge cases (deadline drift from JS Date.now() imprecision, the remainingTimeout > 100 boundary condition). Removing it entirely is the right call.

---

Issues

WASM runtime passes the signal but nothing handles it. WasmCoreRuntime.actorQueueWaitForNamesAvailable now forwards signal via callHandleAsync, but unless the WASM side has a matching wait_for_names_available that accepts and honours a CancellationToken, the parameter is silently dropped. If WASM cancellation is not yet wired, this should either be documented or the parameter should validate and throw an explicit "not yet supported" error rather than silently ignoring it (per the fail-by-default rule in CLAUDE.md).

The createCancellationTokenHandle call is awaited but may not need to be. If createCancellationTokenHandle is synchronous for the no-signal case, the await is fine but worth confirming it doesn't introduce an unintended microtask delay in the hot path where no signal is provided.

No test coverage visible. The PR description references RVT-6297 but there are no new or modified test files in the diff. Given the testing conventions in CLAUDE.md (no mocks, real infrastructure), it would be worth confirming that:

1. Existing driver tests cover waitForNamesAvailable with a signal that aborts mid-wait.
2. The previously-tested timeout behavior still works (the old code had a timeout+signal combination path; the new code relies on the native layer handling both simultaneously).

---

Minor Notes

• The old code explicitly threw actorAbortedError() when the signal was already aborted before the call. The new path relies on createCancellationTokenHandle to cancel the token synchronously in that case, which should produce the same observable error. Worth verifying the error code/group produced by the native layer for a pre-cancelled token matches what callers expect.
• The [...names] spread in the new call is consistent with the old code, so no change there.

---

Verdict

The core change is correct and a clear improvement. The main thing to confirm before merging is whether the WASM runtime silently drops the signal or actually honours it, and whether there is test coverage for the cancellation path.

[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.