ManagementErrorMapper
in package
The §27 status→error mapper (CONTRACT.md §27.4 rule 7).
Deliberately a narrowing of ErrorMapper, not a replacement: three statuses
get a §27 sub-type and everything else falls through to the §2 mapping unchanged, so
the management surface cannot drift from the rest of the SDK on 401, 403 or 5xx.
The three it does claim, and why each parent is the one rule 7 names:
| status | type | parent |
|---|---|---|
404 |
NotFoundError | AuthzError |
409 |
ConflictError | AuthzError |
400,422 |
ValidationError | NetworkError |
Two of them carry more than a status (contract 1.62, §36.3 rule 2 and §36.4). A 409 keeps
the body's reason_code — verbatim, an unknown value included — on ConflictError::getReasonCode(); a caller branches on it, never on the message. A 403 stays
the plain §2 AuthzError (with action and resource_id where the
body has them), and both it and the 409 append the server's own message to their text, as
a 400 does — the write gate's value refusal (session_timeout_secs is above the tenant's cap of 3600) names no permission, so the message is all the person has.
404 under AuthzError is the counter-intuitive one: on a multi-tenant surface the
server answers 404 for another tenant's object so that a caller cannot enumerate
it, and re-drawing that line client-side would undo the protection. 409 keeps the
parent §2 already gave it. 400/422 inherit §2's 400 row.
Table of Contents
Methods
- fromResponse() : AxiamException
- Maps one management response to its typed exception.
Methods
fromResponse()
Maps one management response to its typed exception.
public
static fromResponse(ResponseInterface $response, string $context) : AxiamException
Parameters
- $response : ResponseInterface
-
The error response; its body is a rewindable PSR-7 stream and is only ever read, never consumed.
- $context : string
-
Operation name, prefixed onto the message.