Repository navigation
feat: expose the API's declared error verdict as typed attributes - #360
Conversation
There was a problem hiding this comment.
No issues found across 8 files
Shadow auto-approve: would not auto-approve. This PR does not meet the repository auto-approval settings.
View guided diff | Re-trigger cubic
…rror-fields # Conflicts: # CHANGELOG.md # src/unstructured_client/_version.py
Reconcile release notes and versions without changing authored behavior. Retain main dependency updates and the exact certifi lock record. All nonmetadata files equal the automatic merge of main.
cragwolfe
left a comment
There was a problem hiding this comment.
Reviewed exact head f056cc461a756a1ba2f72f5874f264d5e112857b with GPT Pro. No actionable defects found.
The shared parser preserves strict boolean retry decisions and byte-based JSON encoding detection. The new attributes preserve existing exception behavior, avoid consuming unread streams, and skip parsing for successful-response validation errors. The checked-in tests cover these boundaries and public synchronous/asynchronous failures. The reported encoding fixes are present in the current source.
All 20 reported checks on this head passed. No local tests were run.
(authored by codex)
What
HTTP errors from the client now carry the verdict the API declared, as typed attributes. Callers no longer have to re-parse
err.body.retryable/error_type/error_reason/audience{"detail": "Internal server error"}(declares nothing)None"retryable": "false"NoneNoneThe attributes are on
UnstructuredClientError, so they work for every HTTP error class at any status (SDKErrorfor 4xx,ServerError,HTTPValidationError). That includes the response a failed split-PDF chunk returns.Why
The API publishes
retryable,error_type,error_reasonandaudiencenext todetailon errors it raises deliberately. The client's error models only exposedetail, so any caller that wants to act on the verdict has to parse the raw body itself. Each caller then re-implements the same type checks and tends to get the edge cases slightly different.The retry loop already reads
retryableto stop retrying a declared non-retryable error (0.46.4). The loop and the error attributes now share one parser, so they cannot disagree about what a body declares. Both decode the response bytes, so a UTF-8 BOM or a UTF-16 body is read the same wayresponse.json()reads it.Notes for consumers
ResponseValidationErrorraised on a 2xx response always readsNone, and its (possibly large) body is not parsed again.Validation
make lintis clean (pylint 10/10, mypy).partition/partition_async(400 and 503) through a mocked transport.