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?
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
429status and theRetry-Afterheader 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 a0seconds 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 theRetry-Afterheader. Is this something that happens and, if so, why? How can we ensure that the value the application returns is respected?