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)
frontend-inspector	❌ Build Failed (View Logs)	Web	Jun 3, 2026 at 1:06 am
frontend-cloud	❌ Build Failed (View Logs)	Web	Jun 3, 2026 at 1:06 am
kitchen-sink	❌ Build Failed (View Logs)	Web	Jun 3, 2026 at 1:05 am
website	😴 Sleeping (View Logs)	Web	May 31, 2026 at 3:08 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]

• 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
• main

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

[linear]

RVT-6297

[claude]

Code Review

This PR eliminates a busy-polling anti-pattern from waitForNamesAvailable by wiring a CancellationToken through to Rust core — the same pattern already used by waitForNames, nextBatch, and enqueueAndWait. The change is clean and well-scoped.

Bug: missing asNativeCancellationToken cast in napi-runtime.ts

Every other queue method that passes a signal to the NAPI layer wraps it with:

signal ? asNativeCancellationToken(signal) : signal,

The new actorQueueWaitForNamesAvailable skips this cast and passes signal (typed as CancellationTokenHandle | undefined | null) directly to the NAPI Queue.waitForNamesAvailable method, which expects NativeCancellationToken | undefined | null:

// napi-runtime.ts line 684 — inconsistent with lines 654, 671, 700
.waitForNamesAvailable(names, options, signal);   // ← should use asNativeCancellationToken(signal)

asNativeCancellationToken is a pure type cast (as unknown as NativeCancellationToken), so runtime behaviour is unaffected — but the TypeScript compiler will reject this unless the generated NAPI types are loose enough to accept CancellationTokenHandle directly. It also breaks the established convention used by every sibling method.

Fix: apply the same pattern as the other three methods:

async actorQueueWaitForNamesAvailable(
    ctx: ActorContextHandle,
    names: string[],
    options?: RuntimeQueueWaitOptions | undefined | null,
    signal?: CancellationTokenHandle | undefined | null,
): Promise<void> {
    await asNativeActorContext(ctx)
        .queue()
        .waitForNamesAvailable(
            names,
            options,
            signal ? asNativeCancellationToken(signal) : signal,
        );
}

Everything else looks good

• Rust (queue.rs) — The new signal parameter is passed through queue_wait_opts exactly like wait_for_names. No issues.
• native.ts — The old busy-poll loop (100 ms slices, Date.now() arithmetic, manual timeout tracking) is replaced with the shared createCancellationTokenHandle + try/finally cleanup pattern. This matches the adjacent waitForNames and enqueueAndWait implementations precisely.
• runtime.ts — The signal parameter is added to the CoreRuntime interface, keeping it consistent with the other queue method signatures.
• wasm-runtime.ts — The additional signal argument is forwarded to callHandleAsync. Whether the wasm backend actually honours it depends on the wasm implementation, but the interface change is correct.
• No unintentional scope creep — the diff is tightly scoped to the one missing 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.
• Jun 3, 1:04 AM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jun 3, 1:06 AM UTC: Graphite rebased this pull request as part of a merge.
• Jun 3, 1:06 AM UTC: @abcxff merged this pull request with Graphite.