I haven't been able to find this in the related tasks: what does the error response you'll get look like? and is there some way to "force" an error response to test client libraries?

In T412585#11458421, @matmarex wrote:

I haven't been able to find this in the related tasks: what does the error response you'll get look like? and is there some way to "force" an error response to test client libraries?

This will be a standard 429 with a Retry-After header, which *should* be handled correctly by most HTTP client libraries.

We also have the option to give more information via X-RateLimit headers but I don't know if that is desirable or supported by any of the other rate limiting enforcers on our stack (haproxy, varnish).

In T412585#11458421, @matmarex wrote:

is there some way to "force" an error response to test client libraries?

Hm... That is unfortunately not easily done, since the "shadow mode" flag is in the cinfiguration of the rate limiter, it cannot be controlled per request. What we may end up doing is enabling the rate limit only on one route, for testing.

In T412585#11461635, @daniel wrote:

In T412585#11458421, @matmarex wrote:

is there some way to "force" an error response to test client libraries?

Hm... That is unfortunately not easily done, since the "shadow mode" flag is in the cinfiguration of the rate limiter, it cannot be controlled per request. What we may end up doing is enabling the rate limit only on one route, for testing.

Some way to test this in production would be really helpful to have, especially for complex scenarios like CORS requests (T418969), which are difficult to exactly replicate locally. Maybe there could be a WikimediaDebug option or something.

Create a global group like rate-limit-testers, make it emit an rlc, make the rate limit for that class 0?

A dedicated WikimediaDebug flag would be nicer for sure, but presumably harder to implement.

In T412585#11671606, @matmarex wrote:

In T412585#11461635, @daniel wrote:

In T412585#11458421, @matmarex wrote:

is there some way to "force" an error response to test client libraries?

Hm... That is unfortunately not easily done, since the "shadow mode" flag is in the cinfiguration of the rate limiter, it cannot be controlled per request. What we may end up doing is enabling the rate limit only on one route, for testing.

Some way to test this in production would be really helpful to have, especially for complex scenarios like CORS requests (T418969), which are difficult to exactly replicate locally. Maybe there could be a WikimediaDebug option or something.

I'm testing a Windows client app and associated library, and using Fiddler2 scripting to rewrite a 200 response's headers as a 429 at a rate I can control. That's something of an effort but at least I can customize the logic. Add the code to OnPeekAtResponseHeaders() if you're interested.