The Retry-After header is (potentially) overridden by App Runner
- Dominant language
- No language data
- Stars
- 301
- Forks
- 15
- PR merge metrics
- No merged PRs in 30d
Description
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?
Contributor guide
Assessment
This issue has not been assessed yet.