[Discussion]Configurable error handling and fault sequences for the API Platform gateway

[SavinduDimal]

1. Problem

Two distinct problems share one trigger point.

1. Acting on the error — do something when a request fails: publish an event to a SIEM or event bus, notify a webhook, increment an external counter (execute customizable code when an error occurs).
2. Shaping the error — A gateway-generated error is emitted as JSON regardless of what the client speaks.
   • A SOAP client cannot parse a JSON body. It surfaces a transport error, not the fault we described. The response is a protocol violation.
   • MCP and A2A are JSON-RPC. A bare {"error":"..."} is not a JSON-RPC error object; clients are not required to understand it.
   • A REST client that asked for application/xml gets JSON.

They share a trigger — "a request failed" — and nothing else:

	Fault policies (§1.1)	Error shaping (§1.2)
Nature	operator-authored behaviour	protocol conformance
Configurable	yes, it is the point	no — one correct shape per protocol
Default	off (side effects need consent)	on (a SOAP API is broken without it)
Resolved	per deployment	per request
Failure if absent	no notification	invalid response

Two different defaults, two different configurability answers. They are separate
components with separate switches.

2. Error sources

Four sources. Which one produced an error decides both whether an operator cares and whether the engine can even see it.

flowchart LR
    C([Client]) --> E[Envoy router]
    E -->|ext_proc| P[Policy engine]
    P --> E
    E --> U([Upstream])

    A["<b>A · gateway</b><br/>policy / guardrail<br/>rejection"]:::gw
    B["<b>B · backend</b><br/>upstream returned<br/>an error status"]:::be
    R["<b>C · router</b><br/>no healthy host,<br/>timeout, conn refused"]:::rt
    N["<b>D · no route</b><br/>matched no API"]:::nr

    P -.produces.-> A
    U -.produces.-> B
    E -.produces.-> R
    E -.produces.-> N

Loading

Source	Produced by	Reaches the engine?	Example
A · gateway	policy engine	yes — it built it	guardrail 422, auth 401, ratelimit 429
B · backend	upstream	yes, as a normal response	backend's own 500, 404 for a missing record
C · router	Envoy	yes — verified	no healthy upstream, connect timeout
D · no route	Envoy	no — ext_proc disabled on that route	request matching no API

Source D does not, and cannot without a config change. The catch-all route explicitly
disables ext_proc (translator.go:846). See §13.

3. Solutions

Option 1 — Declarative error-response configuration (Initial approach - rejected)

Addresses need 1. A global document plus a per-API section, both shaped like an OpenAPI Responses Object, customising the body, media type and status code per error status.

spec:
  errorResponses:
    responses:
      "401":
        content:
          application/json:
            example: { code: 401, message: "Authentication required", requestId: "${requestId}" }
      "504":
        x-status-code-override: 502
        content:
          application/json:
            example: { code: "${statusCode}", message: "Upstream did not respond" }

The property relevant to the options below is that this is a renderer: it resolves an entry, negotiates the media type, substitutes placeholders and replaces the body. It performs no I/O. For sources C and D the body is produced when configuration is deployed rather than per request, which is why request-scoped placeholders such as ${requestId} cannot carry values for those sources. The option therefore addresses need 1 across all four sources, and does not address need 2.

Option 2 — Fault sequence (proposed for need 2)

A per-API, ordered list of policies that executes only when a request fails.

spec:
  policies:
    - name: regex-guardrail
      version: v1

  faultPolicies:
    - name: log-message
      version: v1
    # Note the `response:` block. This policy participates in the response phase only
    - name: interceptor-service
      version: v1
      params:
        response:
          url: https://siem.internal.example/gateway-faults
    - name: set-headers
      version: v1
      executionCondition: "response.ResponseStatus >= 400"
      params:
        response:
          headers:
            - name: x-fault-ref
              value: contact-support

OR

spec:
  faultFlow:
    faultPolicies: [...]
    errorReshape:
      enabled: false // Default `true`

The sequence executes over the error response, using the same contracts as a response-phase policy. The consequence is that no fault-specific policy type is required and the existing policy catalogue works on the fault path unchanged. Entries are validated with the same names, versions and parameter schemas as normal policies.

Which function an entry is invoked through is resolved per entry, because the catalogue is split between the two response contracts:

Contract implemented	Examples
OnResponseHeaders	set-headers, remove-headers, cors, basic-ratelimit, mcp-ratelimit
OnResponseBody	interceptor-service, and every response guardrail (word-count, regex, content-length, url, ...)
Both	log-message, advanced-ratelimit, token-based-ratelimit

An entry is dispatched through the body contract when it implements one, and through the header contract otherwise. This is not a detail: a sequence supporting only one contract would silently skip roughly half the catalogue — including interceptor-service, the policy that most directly satisfies "notify a third party" — with no error raised, because a policy that does not implement the expected contract is simply never called.

The body contract is preferred where available because it is a superset: it carries the error body, so an entry can transform the error (wrap it, lift fields out of it) rather than only replace it. Entries execute one at a time so declaration order holds across a sequence mixing both kinds.

Trigger points

A single trigger cannot cover the errors the gateway produces, so there are three.

flowchart TB
    Chain["Request policy chain"] -- "policy rejects the request" --> SC["Gateway builds the error response"]
    SC --> T1["T1 — the gateway generated the error"]
    Chain -- "continues" --> Resp["Response header phase"]
    Resp --> Body["Response BODY phase"]
    Body --> Q{"who produced the error?"}
    Q -- "a response-body policy<br/>overrode the status" --> T3["T3 — response-body rejection"]
    Q -- "backend or router,<br/>passing through" --> T2["T2 — pass-through error"]
    Q -- "no error" --> Ok["normal response — sequence never runs"]
    T1 --> FS["FAULT SEQUENCE, in declaration order"]
    T2 --> FS
    T3 --> FS

Loading

T1 is required because the response phase is not reached once a policy has rejected a request; without it a guardrail 422 on the request path would never enter the sequence.

T2 covers errors the gateway did not generate — a backend error passing through, or a router local reply (503/504), which does traverse the external processor.

T3 covers a response-body policy rejecting a response. It needs its own trigger because such a policy rejects by overriding the status rather than short-circuiting the chain, which is what T1 detects; and the override happens after the response-header phase, where the status was still the upstream's success value. Response guardrails reject exactly this way, so without T3 a guardrail rejecting a response would be invisible.

T2 and T3 both run in the response-body phase, so body-contract entries receive the error body. They are distinguished by who produced the error, not by where they run — and that distinction is what keeps the threshold rule below correct. Running the sequence in the body phase requires response-body processing to be enabled for the route, so attaching a fault sequence enables it; otherwise the sequence would never fire for an API whose own policies do not need the body.

Under T2, an entry with no executionCondition runs only at status 500 and above. A 404 for a missing record is routine REST traffic rather than a fault, and firing on all of them would make the feature noisy from the first deployment; an entry opts into 4xx explicitly. T1 and T3 are exempt, since an error the gateway generated is a fault by construction — and a guardrail rejection is a 4xx.

What a fault policy is told

Beyond the error itself, each entry receives fault metadata: the trigger, the phase, the status, the upstream's status before any policy changed it, and which policy caused the failure. That last field is what turns a notification from "a 422 happened" into "word-count-guardrail rejected this response".

Attribution is deliberately absent under T2: no policy causes a backend error or a router local reply, and naming one would be misleading — the trigger already identifies the kind of error.

Coverage: sources A, B and C. Source D is not covered, because no API matched and therefore no per-API sequence can be selected.

Behaviour

• Never runs on a successful response. Fault entries are held separately from policies, so they cannot execute in the normal request or response phases.
• Runs at most once per request, which prevents an error raised inside the sequence from re-entering it.
• A failing entry never fails the request — the client receives the original error.
• An unresolvable entry is rejected at deployment; one that cannot be initialised is skipped with a warning, leaving normal traffic unaffected.
• An entry may replace the response entirely, so an external service can determine what the client sees. An entry on the body contract may also transform the existing error rather than replacing it.
• Entries must be response-phase policies, since the sequence operates on the error response. A request-phase-only policy is not eligible — the respond policy, for instance, cannot be used in a fault sequence.
• Notifications should be asynchronous by default. A fault sequence runs when the system is already degraded, so a synchronous outbound call converts a fast error into a slow one, once per failed request.
• An error raised while a response is being streamed is not covered. By the time a chunk has been forwarded, the status and headers are already with the client, so the error cannot be reshaped — the protocol offers no way to retract them. A notification-only hook for that case is possible, but it must be labelled as such: an entry that tried to replace the response there would appear to work and silently not.

Option 3 — Fault events through the access-log pipeline

Also addresses need 2, by a different route: emit a fault event from the existing analytics pipeline and add a configurable webhook publisher alongside the existing publishers.

Because that pipeline is driven by router access logs rather than by the policy engine, it is the only mechanism that observes all four sources, including the no-route 404 — and also the only one that cannot identify which policy failed without additional metadata being attached. It is global rather than per-API, runs after the response has been sent, and does not execute user-supplied logic.

That makes it complementary to Option 2 rather than a replacement: Option 2 for per-API logic that may influence the response, Option 3 for uniform fault telemetry across every source.

Option 4 — A new SDK OnError() hook

A dedicated interface implemented by fault-specific policies.

For: type-safe. A fault policy could not be mis-configured into the normal chain.

Against:

• Loses catalogue reuse, the feature's main advantage. interceptor-service,
  log-message, respond and every guardrail work on the fault path unchanged; with
  OnError each would need re-implementing.
• Fixes no coverage gap. Source C already works, source D can't work at any layer
  (no chain is selected), streaming is blocked by HTTP rather than by the interface.

Decision: not as a replacement. If the type-safety argument wins later, add it as an
optional additional interface — checked first, falling back to the response hooks — never
instead of them.

[SavinduDimal]

Open questions

A. Naming and configuration shape

• 1. Rename faultSequence (ex: errorPolicies)?
• 2. Flat configuration, or nested under a common parent?

B. The canonical error model

• 1. What is the code numbering scheme?
• 2. Is code a string or an integer?
• 3. Is the longer detail included by default?
• 4. Does the model need a request/response direction field?

C. What error shaping is allowed to do

• 1. Does shaping change the HTTP status, or only the body?
• 2. Does shaping touch bodies that already have a deliberate author?
• 3. For REST APIs, is shaping on or off by default?
• 4. Instead of error shaping, shall we introduce fault policies for each API kind that needs it?

D. Scope of the first release

• 1. Is a gateway-wide error-policy list in scope (global error policies), and may an API override it?
• 2. Should unmatched requests (the no-route 404) reach the policy engine?

E. Follow-on work to schedule

• 1. Authentication challenges on MCP APIs — guidance, or a different default?
• 2. Publish the infrastructure failure reason in analytics events?
• 3. Reconcile with the declarative error-response configuration work

F. Other

• 1. A guardrail's fault notification must not carry the blocked content by default, since that is precisely the data the guardrail exists to prevent leaving. Should including it be possible at all, even as an explicit opt-in? Note this becomes sharper on the body contract, where the entry now receives the error body directly.
• 2. Should a fault entry be distinguishable from an ordinary response policy at the type level? Today the two are identical, so nothing prevents a notification policy being configured under policies, where it would fire on every successful response instead of only on failures. A dedicated OnError contract would make "faults only" a guarantee rather than a convention — but adopting it as the only contract would forfeit reuse of the existing catalogue, which is Option 2's main advantage. An optional additional contract, checked before the two response contracts, would give the guarantee without that cost.
• 3. Should the fault sequence run for a response that is being streamed, in notification-only form? It is the one part of source A the mechanism cannot cover, and streaming responses are exactly where the LLM-facing guardrails are used.

[SavinduDimal]

Context for section B

Gateway error bodies currently disagree on both field names and their meanings: the class of an error lives in error for the authentication family and type for the guardrail family; message carries four different meanings across the catalogue (a human summary, a nested object, a short code name, and a full sentence with no class beside it); and some errors are not structured at all. A reshaping stage therefore cannot derive its inputs by parsing bodies — a canonical description has to travel alongside the body.

Current suggested canonical error format:

type GatewayError struct {
    Code        string // stable machine identifier
    Type        string // authentication | authorization | throttling |
                       // guardrail | upstream | routing
    Direction        string // Request | Response
    Message     string // short human summary, always safe to return
    Description string // longer detail — MAY be withheld
    Source      string // gateway | backend | router | noRoute  (§7)
    Policy      string // which policy failed; empty = no policy did
}

type ImmediateResponse struct {
    StatusCode int
    Headers    map[string]string
    Body       []byte
    IsFault     bool   //NEW
    Error      *GatewayError   // NEW
    ...
}

Without a defined scheme, code is another free-text field and adds nothing over the human-readable message. The constraint is that MCP and A2A both sit on JSON-RPC, whose error codes are numeric with a reserved range (-32768 to -32000), so any scheme has to coexist with it rather than collide.

[SavinduDimal]

Meeting Notes 17/08/2026

• The meeting initialized a discussion on fault policy architecture for API Gateway error handling and standardized response message formatting.
• We do not need to act or reshape errors according to protocol for the backend generated errors.
• Proposed model (merge of option 2 and option 4 described above):
  • Establish unified error code structures for all policies to ensure consistent client-side response handling.: GatewayError
  • Introduce a boolean attribute to the ImmediateResponse action to convey this should be handled in the fault flow: IsFault

type ImmediateResponse struct {
    StatusCode int
    Headers    map[string]string
    Body       []byte
    IsFault     bool   //NEW
    Error      *GatewayError   // NEW
    ...
}

• Instead of using OnResponseHeader, OnResponseBody execution in fault policies, introduce onError function that should be executed for the policies that can be used as fault policies.
  • We need to add this onError function to all the existing policies that we are supposed to use as fault policies
  • This approach is much cleaner

[SavinduDimal]

Meeting Notes 18/08/2026

• Fault policies will be executed in Resource level fault policies > API level fault policies order
• A new SDK OnError() hook will be introduced.
• Discussed the pros and cons of two different faultPolicies execution (use the same policies list that we have/ introduce new faultPolicies list). Decided to go with the following.

spec:
  faultPolicies:
    - name: log-message
      version: v1
    - name: interceptor-service
      version: v1
      params:
        error:
          url: https://siem.internal.example/gateway-faults
    - name: set-headers
      version: v1
      params:
        error:
          headers:
            - name: x-fault-ref
              value: contact-support

• If a policy need to be used as a faultPolicy, it should have onError function defined in the policy.
• Following SDK changes will be introduced

type ImmediateResponse struct {
    StatusCode int
    Headers    map[string]string
    Body       []byte
    IsFault    *bool          //NEW 
    Error      ErrorResponse   // NEW
    ...
}

// Unified error response for gateway generated errors
type ErrorResponse struct {
    Code        string // stable machine identifier
    Type        string // authentication | authorization | throttling |
                       // guardrail | upstream | routing
    Direction   string // Request | Response
    Message     string // short human summary, always safe to return
    Description string // longer detail — MAY be withheld
    Policy      string // which policy failed; empty = no policy did
    Guardrail   GuardrailError // guardrail specific info
}

• Error reshaping for protocol specific errors will be handled like a system policy. For the API kinds that needs to be considerate about the error response format (SOAP, MCP, A2A) a fault-formatter system policy will be attached.
• All the policies will have a unified error response in the struct ErrorResponse
  • We will try to follow the error structure and error codes used in the API-M (need to check the feasibility)
• In the current phase global fault policies will not be addressed. Hence no API bound 404 errors will not be handled by the fault flow

[SavinduDimal]

Meeting Notes 04/09/2026

• We need to support upstream (backend) generated error handling as well
• Gateway 404 errors and policy engine generated internal errors (resolver related) will be handled in a different effort
• We have to check the feasibility improve CEL,
  • to identify gateway generated and backend generated errors
  • to use fields in the ErrorResponse (ErrorResponse) in the execution condition
  • users should be able to use execution condition for identify backend generated errors and gateway generated errors
• We have to introduce a OOB policy in gateway-controllers as a fault policy for error body, header customization
• We have to introduce a range of errors codes for guardrail generated errors
  • Have a generic error code and add specific guardrail error codes for specific scenarios
  • Need to specifically identify different guardrail errors with different guardrail rejections (ex: hate content, sexual content, self-harm content, violence content)
• When releasing major policy versions, we can change output error messages of the policies (do not break any fundamental flows of the policy)
• Default policy engine error formatter will be used for SOAP and A2A (which will be introduced after this feature). Remove error formatter for all the other existing cases. The current errors (before the feature) will be forwarded to clients without any changes.

[SavinduDimal]

Update

Added Configurations

[policy_engine.fault_policies]
handle_upstream_faults = false   # default

• A policy's own rejection always reaches the fault policies. A failure the upstream or the router produced reaches them only when the deployment opts in.

Condition	handle_upstream_faults = false (default)	handle_upstream_faults = true
Policy rejection	fault policies run	fault policies run
Backend error status (≥ 400)	ordinary response: response policies run, fault policies do not	fault policies run instead of the response policies
Router failure (no healthy host, timeout, refused)	ordinary response	fault policies run instead of the response policies
Streamed upstream error	streams as before	buffered, so the fault policies see the whole body
Default error formatter (A2A)	applies	applies

Management API Changes

Kind	Schema (management-openapi.yaml)	Field	Scope
RestApi	APIConfigData	spec.faultPolicies	every operation
RestApi	Operation	spec.operations[].faultPolicies	one operation, runs first
Mcp	MCPProxyConfigData	spec.faultPolicies	every operation
LlmProvider	LLMProviderConfigData	spec.globalFaultPolicies / spec.operationFaultPolicies	API / path+method
LlmProxy	LLMProxyConfigData	spec.globalFaultPolicies / spec.operationFaultPolicies	API / path+method
Agent (A2A)	A2AOperationConfigs	spec.a2a.operationConfigs.faultPolicies	every A2A operation
Agent (A2A)	A2AOperationConfig	…operationConfigs.operations[].faultPolicies	one A2A operation
Agent (A2A)	A2APublicAgentCard	spec.a2a.agentCard.public.faultPolicies	public Agent Card route only

example:

apiVersion: gateway.api-platform.wso2.com/v1
kind: RestApi
metadata:
  name: orders
spec:
  displayName: orders
  version: v1.0
  context: /orders/$version
  upstream:
    main:
      url: https://orders.internal
  operations:
    - method: GET
      path: /orders/{id}
      faultPolicies:                       # operation level: runs FIRST
        - name: log-message
          version: v1
          executionCondition: 'fault.Status >= 500'
          params: { fault: { payload: true } }
  policies:
    - name: api-key-auth
      version: v1
      params: { key: X-API-Key, in: header }
  faultPolicies:                         # API level: runs after the operation's entries
    - name: error-response-formatter
      version: v1
      executionCondition: 'fault.Source == "gateway"'
      params:
        template:
          error: { code: ${Code}, type: ${Type}, message: ${Message} }
          requestId: ${RequestID}
          status: ${Status}

SDK Changes

• PR: [SDK] Add SDK changes for the API Platform Gateway fault flow feature #3632

Error formatter

• Default error formatter will not be enabled to existing API kinds in API Platform Gateway 1.2.0. Currently it will only be used for A2A APIs
• If there are no fault policies that writes error response body, all the policy errors will be similar to old error messages (Despite of using new or old versions of policies (normal policies))

Analytics Changes

• Before the feature analytics collector did not work when a policy error (ImmediateResponse) happen. System policy was skipped.

"errorType": "OTHER",
"error": {
  "errorCode": 422,
  "errorMessage": "UNCLASSIFIED"
}

• After this feature analytics will be collected in the fault flow since analytics system policy has been added as a fault policy.

"errorType": "OTHER",
"error": {
  "errorCode": 422,                         // unchanged: the HTTP status
  "errorMessage": "UNCLASSIFIED",           // unchanged: from the status
  "wso2ErrorCode": 906201,                  // NEW: the fault code
  "type": "guardrail",
  "direction": "Response",
  "summary": "Violation of applied word count constraints detected",
  "policy": "word-count-guardrail",
  "policyPhase": "response_body",
  "source": "gateway",
  "originalStatus": 200,
  "guardrail": {
    "name": "word-count-guardrail",
    "action": "GUARDRAIL_INTERVENED",
    "reason": "Violation of applied word count constraints detected"
  }
}

Changes to the shipped policies

• Rejections set IsFault: true and Fault with a code from the SDK (policy.FaultCode*, policy.GuardrailCode*) and a class (policy.FaultType*).
• Local duplicated code constants were replaced with the SDK's. 35 per-policy 96xxxx constants were folded into four generic codes (FaultCodeMediationFailed, FaultCodeInvalidRequestBody, FaultCodeUpstreamUnavailable, FaultCodeUpstreamGeneric).
• Guardrails put the internal detail in Description (withheld from clients) and the client-safe text in Message.
• log-message gained OnFault, so it can log a failure as a fault policy.
• set-headers, remove-headers, analytics-header-filter and respond had an OnFault added during the work. It was removed after review: these are business policies, not fault handlers. error-response-formatter covers reshaping an error and log-message covers logging one.
• Following policies were not changed

Policies	Reason
azure-llm-cost, intelligent-model-routing, llm-cost, llm-header-router, semantic-model-routing, semantic-tool-filtering	They never reject a request, so there is nothing to declare.
llm-cost-based-ratelimit, token-based-ratelimit	They delegate the rejection to advanced-ratelimit, which is migrated, and pass its response through unchanged.

The error-response-formatter policy

• A fault policy that renders a gateway error in a shape you define, from a built-in preset or a custom template, and sets the headers that go with it.

Parameter	Type	Purpose
preset	string	openai, canonical, jsonrpc, soap11, soap12. Mutually exclusive with the templates. Default: canonical.
template	object	A structured shape rendered as JSON. A value that is exactly ${Status}, ${JsonRpcCode} or ${JsonRpcID} keeps its JSON type. Values whose placeholders are all empty are left out.
stringTemplate	string	A text shape for XML, SOAP or plain text. Substituted values are escaped for the output syntax.
contentType	string	Content-Type of the body; a preset sets its own. Also drives escaping.
escape	string	auto (from contentType), xml, json, none. For stringTemplate only.
headersToSet / headersToAppend / headersToRemove	array	Header changes on the error. Values may contain placeholders; line breaks and NUL are removed from substituted values.

Placeholders: ${Code} ${Type} ${Direction} ${Message} ${Description} ${Policy} ${PolicyPhase} ${Source} ${Status} ${RequestID} ${OpenAIType} ${JsonRpcCode} ${JsonRpcID} ${Soap11Code} ${Soap12Code}.

References

• https://docs.google.com/document/d/1AC9H2_IFvhDoc_FCOg0j71h550dubsCIYJnYdk4cgq0/edit?usp=sharing

[npamudika]

GraphQL error shaping with faultformat

GraphQLApi routes have the same problem this feature fixes for A2A. A GraphQL client expects {"errors":[{"message", "extensions"}]}, but gateway errors on those routes come back as {"error": ...}. That covers rejections from jwt-auth, api-key-auth and rate limiting, the engine's 500s, and router failures. Only graphql-authz (new policy added via wso2/gateway-controllers#316) uses the GraphQL envelope, and it carries no code. I'd like to add GraphQL to the default formatter. Some of this touches PR #3622 and the SDK, so raising it here first.

1. Enable formatting for GraphQLApi (PR 3622)

• Add policy.APIKindGraphQL to knownAPIKinds. Today NewKindSet reports "GraphQLApi" as unknown.
• Add it to supportedKinds. The reason given for Agent applies here too: GraphQLApi hasn't shipped (/graphql-apis isn't on main's management API yet), so no client depends on today's bodies.
• Add a GraphQL case to Negotiate that always picks the GraphQL shape, as MCP does. The Accept header only chooses the media type: application/graphql-response+json if the client asks for it, otherwise application/json.
• The HTTP status stays as it is; only the body is replaced.

2. Wire format: the extensions contents

{"errors":[{"message":"...","extensions":{
  "code":"900910",
  "classification":"FORBIDDEN",
  "type":"authorization",
  "error_id":"...",
  "guardrail":{...}
}}]}

• code, type, error_id and guardrail use the same names as the JSON shape and the JSON-RPC data block, so they can be found the same way in every shape.
• Open question: what should extensions.code hold?
  -- Many GraphQL clients (Apollo and others) check extensions.code for names like UNAUTHENTICATED or FORBIDDEN.
  -- Our gateway codes (900910, …) are what analytics and API-M users key on.
• Proposal: keep code as the gateway code for consistency across shapes, and add classification. That is a fixed mapping from FaultType, held in the renderer:

FaultType	classification
authentication	UNAUTHENTICATED
authorization	FORBIDDEN
validation	BAD_REQUEST
throttling	RATE_LIMITED
guardrail	GUARDRAIL_INTERVENED
upstream, routing, internal, other	INTERNAL_SERVER_ERROR

The mapping needs no SDK change. The alternative is to put the Apollo name in code and the gateway code under another key, which suits GraphQL clients but breaks consistency with the other shapes.

• As with the other renderers, Description is never rendered.