Skip to content

fix(runtime): honor isRetryable flag in provider retry classifier - #3812

Open
0xMudit wants to merge 1 commit into
apache:mainfrom
0xMudit:fix/3756-retry-classifier-isRetryable
Open

fix(runtime): honor isRetryable flag in provider retry classifier#3812
0xMudit wants to merge 1 commit into
apache:mainfrom
0xMudit:fix/3756-retry-classifier-isRetryable

Conversation

@0xMudit

@0xMudit 0xMudit commented Aug 25, 2026

Copy link
Copy Markdown

Summary

Fixes #3756

The AI SDK wraps TLS/transport failures as \APICallError\ with \isRetryable: true\ and a message like \Cannot connect to API: . Maka's \providerRetryMetadata\ did not check this flag or walk the \cause\ chain, so these failures were classified as non-retryable and the turn exited immediately.

Changes

  • **\provider-error-classification.ts**: Added \isRetryableInChain()\ helper that walks up to 8 levels of the error's \cause\ chain looking for \isRetryable: true. Called as a fallback when the classifier doesn't surface a retryable class, or when
    ormalizeProviderError\ returns undefined.
  • **\provider-error-classification.test.ts**: Added two regression tests:
    1. TLS failure with the exact message from the issue report (\decryption failed or bad record mac) — verifies it's now retryable.
    2. Wrapped cause error with \isRetryable: true\ when the top-level error has no structured evidence — verifies the cause flag is honored.

Verification


  • pm --workspace @maka/runtime run build: passes

  • pm --workspace @maka/runtime test: 17/17 pass (including 2 new regression tests)

  • pm --workspace @maka/core test: 656/656 pass

  • pm run lint: passes

  • pm run format:check: passes

AI use

  • Generative tooling made a substantive contribution

Tool(s) and scope: opencode/big-pickle — diagnosed root cause, implemented fix and regression tests

Checklist

  • Tests cover the change and fail without it
  • Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

  • Yes — transport failures marked retryable by the AI SDK are now retried instead of terminating the turn

… retry classifier

The AI SDK wraps TLS/transport failures as APICallError with isRetryable:true
and a 'Cannot connect to API: <cause>' message. Maka's providerRetryMetadata
did not check this flag or walk the cause chain, so these failures were classified
as non-retryable and the turn exited immediately (apache#3756).

- Check isRetryable on the error and up to 8 levels of cause chain
- Add regression tests for the exact TLS message from the issue report
- Add test for isRetryable on a wrapped cause error

Generated-by: opencode/big-pickle

@Astro-Han Astro-Han left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update on b61f988a42:

[P2] isRetryableInChain ignores outer isRetryable:false, causes false retry

APICallError(400,false,cause=APICallError(true)) is judged retryable, sending a hard 4xx into up to 10 provider retries. Fix: give nearest explicit boolean (especially false) authority and add regression test.

Also P3: RetryError.lastError unwrapping inconsistency between classifier and helper — unify boundary.

简体中文重试判断越过显式不可重试标记。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

runtime: transport failures wrapped as "Cannot connect to API" are never retried; the classifier ignores the AI SDK isRetryable flag and the error cause

2 participants