[charan-rathore]

What this fixes

The voice compute cache kept a promise even when it rejected. A failed compute stayed in the cache for good, so it used up one of the six turns allowed per call, and retrying with the same toolCallId failed again every time.

Changes

• Remove the failed promise from the cache when it rejects, and rethrow the original error.
• Concurrent calls with the same key still share one in-flight promise.
• Successful results are still cached, and the six-turn cap is unchanged.

Tests

Two regression tests (a failed compute can be retried, and the failure is not left in the cache). They fail on the base commit. I also added a test that guards the success cache and the six-turn cap. The tests use no external API.

Results below are from the person who prepared the change; I did not rerun them. Full suite: 34 files, 159 tests pass. Lint, typecheck, format check and production build pass (the build prints a chunk size warning that was already there). No dependency or lockfile changes.

[NathanTarbert]

Thanks @charan-rathore. Clearing only the failed entry is a nice small change. Calls that are in flight still share one promise and successful results stay cached, and the comment makes the intent easy to follow.

One thing worth weighing. job.calls is also what the six-turn cap counts, so removing failed entries means failed turns stop counting toward it. With a provider that keeps failing, a call can now start as many turns as the model asks for, not six. Each one can still use up to 90 seconds of model time and run tools before it fails. The test "does not count failed compute calls toward the six-turn limit" shows this is deliberate. I just wanted to name the cost. If the goal is mainly to let the same tool call retry, one option is to keep counting every attempt toward the cap while still allowing a retry under the same id. Happy to go with whichever the maintainers prefer.

[charan-rathore]

Thanks, good catch. Pushed 642afcd: the cap now counts attempts instead of the size of the call map. A failed turn is still removed from the map so the same tool ID can retry, but every attempt, including a retry of the same ID, counts toward the six. I replaced the old "does not count failed calls" test with two that fail on the previous commit: six failed IDs hit the cap on the seventh, and six retries of one ID do too.

Ran: full vitest (160 passed), tsc, prettier on the two files. Not run: eslint beyond those files.

Prepared with AI assistance; Charan Rathore is directing and responsible for this PR.

[NathanTarbert]

Thanks @charan-rathore, that's exactly the shape I had in mind. A failed id can retry, and every attempt still counts toward the six. The two tests for six failed ids and six retries of one id pin down both halves nicely.

Looks good to me.

[jerelvelarde]

Useful voice tool retry fix: failed computations can be retried, successful results remain cached, and all attempts still consume the bounded six-attempt budget. Checked concurrent failure deduplication, successful retry caching, cancellation, and rejection after call termination. No actionable security or correctness findings. Individual full checks pass; combined tree passes 233 tests, type checking, lint, formatting, and production build. Live provider calls were not exercised.