Skip to content

feat(proxy): add error_type zod enum to all LLM proxy error responses#2491

Merged
chrarnoldus merged 3 commits into
mainfrom
feat/error-type-enum
Apr 16, 2026
Merged

feat(proxy): add error_type zod enum to all LLM proxy error responses#2491
chrarnoldus merged 3 commits into
mainfrom
feat/error-type-enum

Conversation

@kilo-code-bot

@kilo-code-bot kilo-code-bot Bot commented Apr 16, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds a proxyErrorTypeSchema zod enum and an error_type property to every error HTTP response in llm-proxy-helpers.ts. This gives clients a machine-readable, stable error classifier they can switch on instead of parsing free-text error/message strings.

The enum covers all 15 error paths:
invalid_path, invalid_request, temporarily_unavailable, upgrade_required, usage_limit_exceeded, data_collection_required, api_kind_not_supported, stealth_model_error, byok_error, context_length_exceeded, model_not_allowed, forbidden_free_model, model_not_found, feature_exclusive_model, unsupported_field.

Each literal is typed with satisfies ProxyErrorType so the compiler catches any mismatch with the enum.

Verification

  • Ran tsc --noEmit against apps/web — no type errors in the changed file
  • Ran pnpm format — no formatting issues
  • Pre-commit hooks (lint, typecheck, format) passed on push

Visual Changes

N/A

Reviewer Notes

  • The error field is left unchanged so existing clients are unaffected; error_type is purely additive.
  • usageLimitExceededResponse has a nested error object (consumed by the extension); error_type is placed at the top level alongside it.

@kilo-code-bot

kilo-code-bot Bot commented Apr 16, 2026

Copy link
Copy Markdown
Contributor Author

Code Review Summary

Status: 4 Issues Found | Recommendation: Address before merge

Overview

Severity Count
CRITICAL 0
WARNING 4
SUGGESTION 0

Fix these issues in Kilo Cloud

Issue Details (click to expand)

No new diff-line issues in the incremental changes. The remaining warning-level gaps are unchanged pass-through/auth paths that still return some proxy errors without error_type.

Other Observations (not in diff)

Issues found in unchanged code that cannot receive inline comments:

File Line Issue
apps/web/src/app/api/openrouter/[...path]/route.ts 645 When makeErrorReadable() does not rewrite an upstream 4xx/5xx, the route still returns wrapInSafeNextResponse(response), so many provider error bodies pass through without error_type.
apps/web/src/app/api/openrouter/embeddings/route.ts 306 Upstream embedding failures are still forwarded with wrapInSafeNextResponse(response), which means clients can still receive proxy errors without error_type.
apps/web/src/app/api/fim/completions/route.ts 90 The route still returns authFailedResponse from getUserFromAuth() unchanged, so unauthenticated or forbidden FIM requests keep the generic { success: false, error } payload without error_type.
apps/web/src/app/api/fim/completions/route.ts 279 Non-local FIM provider errors are still returned via wrapInSafeNextResponse(proxyRes), so upstream 4xx/5xx responses are not normalized to include error_type.
Files Reviewed (5 files)
  • apps/web/src/lib/proxy-error-types.ts - 0 issues
  • apps/web/src/lib/llm-proxy-helpers.ts - 0 issues in diff
  • apps/web/src/app/api/openrouter/[...path]/route.ts - 1 issue outside diff
  • apps/web/src/app/api/openrouter/embeddings/route.ts - 1 issue outside diff
  • apps/web/src/app/api/fim/completions/route.ts - 2 issues outside diff

Reviewed by gpt-5.4-2026-03-05 · 764,953 tokens

kilo-code-bot Bot added 2 commits April 16, 2026 07:24
…cover all route-level errors

- Move proxyErrorTypeSchema to dedicated proxy-error-types.ts
- Rename forbidden_free_model => discontinued_free_model
- Add error_type to inline error responses in openrouter, embeddings, and FIM routes
@chrarnoldus chrarnoldus merged commit dff71cb into main Apr 16, 2026
15 checks passed
@chrarnoldus chrarnoldus deleted the feat/error-type-enum branch April 16, 2026 08:55
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