fix(resolve): attach SUBREQUEST_HTTP_ERROR on status-fallback path - #1558
AvnerMaster wants to merge 1 commit into
Conversation
Non-2XX subgraph responses with no GraphQL errors body (empty/non-GraphQL
body, or a null data._entities — typical of an LB/ingress "504 Gateway
Timeout") take renderErrorsStatusFallback, which emitted a bare
{"message":"<status>: <statusText>"} with no extensions.code and never
invoked addApolloRouterCompatibilityError. Only the errors-body path
(mergeErrors) attached the Apollo Router compatibility error.
This left downstream consumers that key on SUBREQUEST_HTTP_ERROR unable to
normalize status-only subgraph failures, so error shape diverged between the
two non-2XX paths (e.g. platform-api-gateway normalized errors-body 5xx to
"Internal Server Error" but passed bare "504: Gateway Timeout" through raw).
When apolloRouterCompatibilitySubrequestHTTPError is enabled and status >= 400,
delegate to addApolloRouterCompatibilityError so status-only failures carry the
same coded error as the errors-body path.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe loader's ChangesStatus fallback compatibility fix
Estimated code review effort: 1 (Trivial) | ~5 minutes Sequence Diagram(s)sequenceDiagram
participant Subgraph
participant Loader
participant Resolvable
Subgraph->>Loader: HTTP response, statusCode >= 400, no errors/data
Loader->>Loader: check ApolloRouterCompatibilitySubrequestHTTPError
Loader->>Resolvable: addApolloRouterCompatibilityError(res) with SUBREQUEST_HTTP_ERROR
Loader-->>Loader: return, skip generic error message
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problem
With
ApolloRouterCompatibilitySubrequestHTTPErrorenabled, every non-2XX subgraph response is expected to carry aSUBREQUEST_HTTP_ERROR-coded error (viaaddApolloRouterCompatibilityError).However, that error is attached only on the errors-body path (
mergeErrors,loader.go:741/788). When a subgraph returns a non-2XX with no GraphQL errors body — an empty/non-GraphQL body, or a nulldata._entities(typical of an LB/ingress504 Gateway Timeout) — the loader takesrenderErrorsStatusFallback(loader.go:502/565), which emits a bare{"message":"<status>: <statusText>"}with noextensions.codeand never invokesaddApolloRouterCompatibilityError.Impact
The two non-2XX paths produce inconsistent error shapes: consumers relying on
SUBREQUEST_HTTP_ERRORto normalize subgraph HTTP failures can normalize the errors-body case but not the status-only case (e.g. a bare504 Gateway Timeoutfrom an ingress/proxy in front of a subgraph).Fix
In
renderErrorsStatusFallback, whenapolloRouterCompatibilitySubrequestHTTPErroris enabled andstatusCode >= 400, delegate toaddApolloRouterCompatibilityErrorso status-only failures carry the same coded error as the errors-body path.Test
Adds
TestArenaGCSafety_ApolloRouterCompatError_StatusFallback(504 + flag on + empty body → codedSUBREQUEST_HTTP_ERROR). New test and the fullpkg/engine/resolvesuite pass, no regressions.Notes
Reported by the monday.com platform API team while migrating from Apollo Router to Cosmo: an
_entitiesfetch hitting a504 Gateway Timeoutreached clients as a raw, uncoded error instead of a normalized one, diverging from the Apollo Router path.