Before You Scroll

If you're here because you have a CORS error and you think it's hiding your real problem, run this command:

This will start up a Chrome instance with web security turned off, which gets CORS errors out of the way leaving you free to debug your response (assuming the CORS error itself isn't your problem).

For the bug in this blog, we spent about 4 hours debugging before we ran the above command, and then had the issue fixed an hour later.

The Background

Recently my pair and I implemented a feature to process some data with a long running GraphQL mutation (about 2 minutes to return a response on a production size data set). There are better ways to do this without such a long-running request, but this particular action happens rarely enough we just went with this approach and plan to revisit it later.

The Bug

On our development machines, everything would run just fine, but in our higher environments, we'd get this lovely error in the browser console:

Access to fetch at '[OUR API]' from origin '[OUR FRONTEND]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Some other interesting things we noticed:

1. There were no errors in the server logs.
2. The data processing was actually happening just fine, but the response was buggy.
3. We'd get this message exactly 1 minute after we fired the request, every time.

The Fix

Turns out, because of the long running request, we were bumping up against 2 different timeout limits in our stack, one at our ingress controller, and one at our DNS. It makes sense that we couldn't replicate this locally, since in our dev environments there is neither ingress nor DNS. Tweaking those limits was all we needed. Once we launched into a CORS free world using this command:

Everything started falling into place!