Skip to content

Case study

A GraphQL failure that was really CORS

Chasing a generic userContext error down to the real, config-level cause.

All case studies
TenacityDebuggingConfiguration

data: null

Symptom

CORS config

Cause

multi-region

Scope

01

Situation

A GraphQL userContext query returned data: null with errors, failing in multiple regions — the kind of generic error that invites a wrong fix at the resolver layer.

02

Task

Find why the query failed, rather than patching symptoms.

03

Action

I inspected the configuration files from inside the running pod, then found the pod logs were full of 'Not allowed by CORS' — pointing the investigation at CORS/origin configuration, and confirmed it reproduced across regions.

browserCORS filterorigin checkGraphQL resolverNot allowed by CORS — rejected upstream
The resolver was fine; the request was being rejected upstream by CORS before it could resolve.
The real error, in the pod logstext
# GraphQL response (misleading):
{ "data": null, "errors": [{ "message": "Internal server error" }] }

# Pod log (the truth):
WARN  o.s.web.cors.DefaultCorsProcessor - Rejected request: Not allowed by CORS
=> fix the origin/CORS config, not the resolver
04

Result

  • Pinpointed a configuration root cause behind a generic GraphQL error, avoiding a wrong fix at the resolver layer.
  • Confirmed the per-region config difference and corrected the origin/CORS configuration.
  • Reinforced: read the pod logs for the real error before changing application code.