Investigate prohibited jurisdiction on api-unavailable
Currently, if api-service
is not available the client app shows a prohibited jurisdiction modal.
That happens because the trigger for the modal is:
err.config.url === '/status' &&
err.config.method === 'post' &&
!err.response
There is no difference for the client code if the request was blocked by AWS or our nginx (client code can not see status code
on an error as well as the name of server responded). In both cases, we get a CORS error which is handled by the browser but not the client code. That's why err.response
is undefined (the request was not sent because CORS preflight failed so no response).
There is a catch in catch: if the error occurs before the request is made, then in catch you will not have the err.response property, because... well... there is no response. So, the catch will catch any error. The same applies in the situations like the one from @fabiorecife when there is no response because of a network failure. Do not treat the err as a HTTP error because this is not always the case.
To solve this problem we need to avoid CORS error from Nginx so err.response
will be undefined only for AWS responses.
Originally we configured CORS on api-service so if api is up and running we have no problems with CORS but once api-service is down Nginx responds to CORS message by himself.
UPD
As a solution, we can configure CORS specifically for /status endpoint:
location /status {
add_header 'Access-Control-Allow-Origin' '*' always;
}
Or even
location /status {
return 204;
}