docs(adr-066): record 4XX/5XX wildcard projection mapping (OAI-13)
This commit is contained in:
@@ -134,6 +134,21 @@ The
|
|||||||
difference is purely the input shape: a full document vs. a single
|
difference is purely the input shape: a full document vs. a single
|
||||||
endpoint.
|
endpoint.
|
||||||
|
|
||||||
|
### Response-key wildcards (review 002 OAI-13)
|
||||||
|
|
||||||
|
`from_openapi` projects OpenAPI response keys onto `HTTP_<status>` error
|
||||||
|
codes, which require a concrete status. Class wildcards map to the first
|
||||||
|
legal concrete status in their implied range: `4XX` → `HTTP_400`, `5XX`
|
||||||
|
→ `HTTP_500`. The declared payload schema of the wildcard response is
|
||||||
|
carried by the projected entry. `default` has no implied status range,
|
||||||
|
so it is not projected (it would advertise an `HTTP_0` code that can
|
||||||
|
never match a callback status) — unmapped upstream statuses surface as
|
||||||
|
the synthesized `HTTP_<actual>` at call time regardless. A concrete
|
||||||
|
status key always outranks a wildcard covering the same range, in both
|
||||||
|
error projection and the success sweep (SSE detection +
|
||||||
|
output-schema selection), where the precedence order is: concrete 2XX
|
||||||
|
statuses, then `2XX`, then `default`.
|
||||||
|
|
||||||
## Consequences
|
## Consequences
|
||||||
|
|
||||||
**Positive**:
|
**Positive**:
|
||||||
|
|||||||
Reference in New Issue
Block a user