fix(sdk/go): return structured APIError instead of flattening error response (closes #436)#442
Conversation
…esponse Issue Agent-Field#436: AI client flattens structured error responses into fmt.Errorf, losing HTTP status code, error type, and error code — preventing callers from distinguishing auth (401) vs rate-limit (429) vs server errors (5xx). Changes: - Add APIError struct with HTTPStatus, Type, Code, Message fields - Implement error interface with IsRetryable(), IsAuthError(), IsRateLimited() - Update doRequest (both streaming and non-streaming) to return *APIError - Callers can now use type assertion to access structured error fields Fixes Agent-Field#436
|
由伟 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
|
Appreciate the contribution here. There are two things to address before this can move forward: first, the CLA assistant check above, including linking the commit author email to your GitHub account; and second, the code changes requested in the review below. Please sort out the CLA/email mismatch, rerun the check, and then take a look at the requested-changes review for the API error handling updates still needed. |
santoshkumarradha
left a comment
santoshkumarradha
left a comment
There was a problem hiding this comment.
Thanks for taking this on. I am requesting changes before this can move ahead. The intent is good, but this does not fully satisfy #436 yet: the issue asks for a structured API error that also preserves the raw response body when parsing fails, and tests for the new behavior. As written, non-JSON error responses in the streaming path can lose the useful raw error text entirely, which is a regression for callers trying to debug upstream failures. Please add the raw-body fallback and the corresponding tests before we move this forward.
3 participants
详见文件