You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a Nest JS service which is compiled and built into a Docker image, hosted on ECR and deployed by App Runner.
We have implemented rate limiting strategies for certain requests and as such we can return responses with a 429 status and the Retry-After header set to a seconds value.
We notice that when this happens on the application deploy to App Runner, the header returned in the response contains a 0 seconds value.
This is not a problem when we run the same service locally or even when we run the Docker image from the ECR locally and logs from the instance deployed to App Runner confirm that the number of seconds is calculated correctly even if we do not receive that number in the response.
It is obviously difficult to confirm, since the system is a black box, but it seems that App Runner may be overriding the value of the Retry-After header. Is this something that happens and, if so, why? How can we ensure that the value the application returns is respected?
The text was updated successfully, but these errors were encountered:
We have a Nest JS service which is compiled and built into a Docker image, hosted on ECR and deployed by App Runner.
We have implemented rate limiting strategies for certain requests and as such we can return responses with a
429
status and theRetry-After
header set to a seconds value.We notice that when this happens on the application deploy to App Runner, the header returned in the response contains a
0
seconds value.This is not a problem when we run the same service locally or even when we run the Docker image from the ECR locally and logs from the instance deployed to App Runner confirm that the number of seconds is calculated correctly even if we do not receive that number in the response.
It is obviously difficult to confirm, since the system is a black box, but it seems that App Runner may be overriding the value of the
Retry-After
header. Is this something that happens and, if so, why? How can we ensure that the value the application returns is respected?The text was updated successfully, but these errors were encountered: