Skip to content

fix(cloud-agent-next): classify failures from APIError response body - #6796

Merged
eshurakov merged 2 commits into
mainfrom
eshurakov/radiant-nebula
Sep 28, 2026
Merged

eshurakov merged 2 commits into
mainfrom
eshurakov/radiant-nebula

Conversation

@eshurakov

Copy link
Copy Markdown
Contributor

Summary

The AI SDK's APIError frequently carries no statusCode, only the raw provider responseBody. Without reading it, known provider failures collapsed into the generic "Assistant request failed" (unknown) bucket.

classifySdkStatus now parses the response body (bounded to 64 KiB, JSON object only) to recover the cause:

  • an error_type token, at the top level or under metadata, mapped through a bounded allowlist
  • a numeric status in status / statusCode / code
  • a known SDK error name such as AI_InvalidResponseDataError

An explicit, well-formed statusCode still wins over the body. An unusable body (not json, '', [], null) stays unknown.

Verification

  • pnpm exec vitest run src/session/safe-failure-projection.test.ts — 187 passed, including new cases for 502 provider bodies, context-overflow tokens, top-level error_type, status precedence, and unusable bodies.
  • pnpm run typecheck (tsgo + wrapper) — passed.
  • pnpm run lint — 0 warnings, 0 errors.
  • pnpm run format:check — clean.

Visual Changes

N/A

Reviewer Notes

The error_type map uses a Map rather than an object so a caller-supplied constructor key cannot resolve an inherited member. The classification stays in the single shared owner (assistant-failure.ts) used by both the safe-failure projection and the control-plane run classifier.

…esponse body

The AI SDK's APIError often carries no statusCode, only the raw provider responseBody. Parse that body (bounded, JSON object only) to recover the gateway status code and error_type token, and recognize AI_InvalidResponseDataError as a provider_unavailable failure.
@kilo-code-bot

kilo-code-bot Bot commented Sep 28, 2026 •

Copy link
Copy Markdown
Contributor

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The zod-based provider-body parser in classifySdkStatus parses each field independently (.optional().catch(() => undefined)), so a malformed sibling no longer discards a valid error_type; explicit statusCode precedence, the 100–599 bound, and unusable-body handling are preserved, and the added test covers the new case.

Files Reviewed (2 files)
  • services/cloud-agent-next/src/shared/assistant-failure.ts
  • services/cloud-agent-next/src/session/safe-failure-projection.test.ts
Previous Review Summary (commit e16cfba)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit e16cfba)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The provider-body failure classification is bounded, prototype-safe, precedence-tested, and does not surface the raw responseBody; no defects found in the changed lines.

Files Reviewed (2 files)
  • services/cloud-agent-next/src/shared/assistant-failure.ts
  • services/cloud-agent-next/src/session/safe-failure-projection.test.ts

Reviewed by deepseek-v4.1-flash · Input: 0 · Output: 0 · Cached: 0

Review guidance: REVIEW.md from base branch main

@chrarnoldus chrarnoldus 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.

maybe some of this can be simplified using zod?

Replace the hand-rolled object and numeric-status guards with a small zod schema. Each field is parsed independently via .catch(() => undefined) so a malformed sibling (e.g. a string code) does not discard a valid error_type; a test pins that per-field tolerance.
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.

2 participants