Skip to content

fix(resolve): attach SUBREQUEST_HTTP_ERROR on status-fallback path - #1558

Open
AvnerMaster wants to merge 1 commit into
wundergraph:masterfrom
mondaycom:fix/subrequest-http-error-status-fallback
Open

AvnerMaster wants to merge 1 commit into
wundergraph:masterfrom
mondaycom:fix/subrequest-http-error-status-fallback

Conversation

@AvnerMaster

Copy link
Copy Markdown

Problem

With ApolloRouterCompatibilitySubrequestHTTPError enabled, every non-2XX subgraph response is expected to carry a SUBREQUEST_HTTP_ERROR-coded error (via addApolloRouterCompatibilityError).

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 null data._entities (typical of an LB/ingress 504 Gateway Timeout) — the loader takes renderErrorsStatusFallback (loader.go:502/565), which emits a bare {"message":"<status>: <statusText>"} with no extensions.code and never invokes addApolloRouterCompatibilityError.

Impact

The two non-2XX paths produce inconsistent error shapes: consumers relying on SUBREQUEST_HTTP_ERROR to normalize subgraph HTTP failures can normalize the errors-body case but not the status-only case (e.g. a bare 504 Gateway Timeout from an ingress/proxy in front of a subgraph).

Fix

In renderErrorsStatusFallback, when apolloRouterCompatibilitySubrequestHTTPError is enabled and statusCode >= 400, delegate to addApolloRouterCompatibilityError so status-only failures carry the same coded error as the errors-body path.

Test

Adds TestArenaGCSafety_ApolloRouterCompatError_StatusFallback (504 + flag on + empty body → coded SUBREQUEST_HTTP_ERROR). New test and the full pkg/engine/resolve suite pass, no regressions.

Notes

Reported by the monday.com platform API team while migrating from Apollo Router to Cosmo: an _entities fetch hitting a 504 Gateway Timeout reached clients as a raw, uncoded error instead of a normalized one, diverging from the Apollo Router path.

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>
@AvnerMaster
AvnerMaster requested a review from a team as a code owner July 1, 2026 13:16
@coderabbitai

coderabbitai Bot commented Jul 1, 2026 •

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: cf7f8e53-34f7-4f86-ae5f-a3be45cf453c

📥 Commits

Reviewing files that changed from the base of the PR and between fb2d52a and 42d398b.

📒 Files selected for processing (2)
  • v2/pkg/engine/resolve/loader.go
  • v2/pkg/engine/resolve/resolve_arena_gc_test.go

📝 Walkthrough

Walkthrough

The loader's renderErrorsStatusFallback function now checks for Apollo Router compatibility mode and, for HTTP status codes >= 400, emits a structured SUBREQUEST_HTTP_ERROR compatibility error instead of a generic status-message error. A new regression test validates this behavior under GC pressure with a 504 status response.

Changes

Status fallback compatibility fix

Layer / File(s) Summary
Emit SUBREQUEST_HTTP_ERROR on status-only fallback
v2/pkg/engine/resolve/loader.go, v2/pkg/engine/resolve/resolve_arena_gc_test.go
Adds an early return in renderErrorsStatusFallback that emits an Apollo Router compatibility SUBREQUEST_HTTP_ERROR when statusCode >= 400, replacing the generic status-message error path, and adds a test asserting this behavior for a 504 response with no GraphQL error/data body.

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
Loading
🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main fix: attaching SUBREQUEST_HTTP_ERROR on the status-fallback path.
Description check ✅ Passed The description directly explains the same fix and test coverage for the status-only non-2XX path.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant