fix(grpc-js): stop retry attempts after the call is cancelled

[phyous]

Problem

When a call with a retryPolicy is cancelled while a retry is waiting out its backoff, RetryingCall keeps retrying. cancelWithStatus() reports the status and cancels the child calls, but it leaves state as 'RETRY' and doesn't clear the backoff timer (the timer handle isn't stored). When the timer fires, it calls startNewAttempt() for a call the application has already cancelled. If that attempt fails with a retryable status, the call continues through its remaining attempts.

This has two visible effects:

• The server runs handlers for cancelled calls. For a client-streaming call cancelled after its first attempt, the server handler ran 3 times instead of once (all maxAttempts).
• Streams leak and can block the channel. reportStatus() has already cleared the write buffer, so a unary attempt sends headers but no message. The server never responds, and the stream stays open until the connection closes. Each one occupies a slot under the server's MAX_CONCURRENT_STREAMS. With a limit of 100 (typical for proxies and load balancers), cancelling 100 calls during backoff makes a later call to a healthy server fail with DEADLINE_EXCEEDED. The same flow succeeds if the calls are cancelled while an attempt is in flight, or if they aren't cancelled at all.

This reproduces with the published 1.14.5 and 1.13.6 releases as well as master. For comparison, grpc-go aborts its backoff wait when the call's context is cancelled.

Fix

Store the retry timer. In cancelWithStatus(), set the state to NO_RETRY so no path can start a new attempt, and clear the retry and hedging timers.

Tests

test/test-retry.ts has a new Retries after cancellation block with two tests. Both fail on master and pass with this change:

• A client-streaming call cancelled during backoff starts only one attempt.
• After 3 unary calls are cancelled during backoff, a new call still succeeds against a server limited to 3 concurrent streams.

Across the rest of the grpc-js test suite, the only failures are the same ones master has in my environment: TLS fixture tests that fail with ee key too small on this OpenSSL version.

I found this with a formal model of the retry state machine and confirmed it with the tests above.

🤖 Generated with Claude Code

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: phyous / name: Philip Youssef (a738dfb)