Access Control Allow Origin header missing on preflight check on cold start

[verneleem]

If my slash endpoint has been unused and entered sleep mode, this is the error I get when I am waking it back up by making a request from the application itself. I can only reproduce this on cold starts of the app after a longer period of time.

After this first error and logging out and logging back in to initiate a reload, the app then moves along normally as expected.

Here are the Headers received during the preflight check after the endpoint has been warmed up.

I will capture the preflight response next time it happens, but the error above is all I captured last time.

I am thinking I can resolve this by putting in some kind of check to make sure that the server is warmed up before sending the first query by adding the option skip: true until the warming cycle has been initiated. (I am using Apollo client if that makes any difference)

@tejas any thoughts on how to await for a warm up before sending a preflight request?

[gja (Tejas Dinkar)]

Is there a timeout that you’ve applied? Also, how long was it since you used the backend last? Couple of hours, or a couple of weeks?

[verneleem]

Here is a similar error captured again. It appears this time to specifically be related to the token header. This is the header being used for auth defined in the schema.

Here are the request headers that result in the error above.

This is happening on this site: https://naughty-swirles-16beb1.netlify.app/

which is being deployed with netlify from this branch: GitHub - verneleem/graphql-kanban at verneleem/prepare-one-click

Simply waiting a little bit and refreshing the page resolves the error and the following preflight request was received

notice it now supplied token as a allowed header.

[verneleem]

@gja

Is there a timeout that you’ve applied?

no, maybe I need to?

@gja

Also, how long was it since you used the backend last? Couple of hours, or a couple of weeks?

This time it was captured working correctly at Tue, 26 Jan 2021 18:16:48 GMT but not working at Wed, 27 Jan 2021 13:35:18 GMT.

maybe you have logs on Slash for this between 27 Jan 2021 13:35:18 GMT and 13:37:23 GMT that might show if slash was asleep and woken up in that time frame.

[verneleem]

maybe I can piggy back on the X-Auth-Token for my auth header instead of using my own custom header token. Would this cause any problems on Slash on the graphql endpoint?

[gja (Tejas Dinkar)]

It very likely was asleep. I’m trying to figure out who gave up, your browser or our ingress controller. If it’s there latter, it’s a bug, as we are supposed to wait for the backend to come up, upto 60s

[verneleem]

Here is some more data from a cold start.

In this case, the client still had a valid JWT, so it was trying to supply this in the request header on the very first GraphQL request to wake up the slash instance:

The first GraphQL Request:

The preflight OPTIONS

30 seconds later the preflight OPTIONS again:

How this is affecting my site:

On the first load of the site after login the site uses GraphQL to find the info for the logged in user (per Auth0). If the user does not exist, then a user is created matching the signed in user.

The problem is that I am expecting the GraphQL request to work the very first time. But it is not. Since it comes back with no user I then try to create a user immediately, which also fails, because Slash is still not up and online. When Slash does finally wake up 30 seconds later, it starts working and getting the user data. However this “finally” sometimes does not appear to happen because a user does not like to sit and stare at an error on the page for 30 seconds.

Needed solution: How can I know when the instance is awake? I can then use a method to “Load” the SPA triggering the slash instance to wake up and await a positive listening state.

Is there a endpoint that signifies that the server is asleep/awake?

Is there some kind of request I can make that will not respond until the server is awake.

By theory, the later question above should be handled by any GraphQL request waiting on the server to wake up. But the 502 returned status of the OPTIONS causes the initial GraphQL request to fail with cors error instead of waiting the 30 seconds.

Thank you @gja for helping work through this.

[verneleem]

@gja

It very likely was asleep. I’m trying to figure out who gave up, your browser or our ingress controller. If it’s there latter, it’s a bug, as we are supposed to wait for the backend to come up, upto 60s

Since the OPTIONS preflight request received status code 502 Bad Gateway server, I do believe this is a bug and the ingress did not wait the 30 seconds longer.