Gehel added a comment.
I'm not sure why we have a retry in the first place. An exponential back-off would be good, or to honor the "Retry-After" HTTP header sent by WDQS on 429 errors.TASK DETAILhttps://phabricator.wikimedia.org/T178445EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/pan
Gehel added a comment.
Looking at logs in logstash, it seems we throttled Recommendation API only when WDQS was overwhelmed by another user. Throttling is done on overall request time and the service was most probably already not responding correctly, or in a reasonable time.
My understanding at t
mobrovac added a comment.
In T178445#3692895, @Smalyshev wrote:
@mobrovac what's the rate the requests are currently sent at? IIRC the limits we have are pretty generous, but depends on the use case of course.
This is the part that I don't understand - the rate of the public end point is 0, whic
Gehel added a comment.
@mobrovac it is possible if we can identify internal traffic. The throttling we apply is bucketed by user agent / IP, so I suspect that all the recommendation API traffic end up in the same bucket.
We could add an exception for specific user agent. Or have Recommendation API
Smalyshev added a comment.
@mborovac what's the rate the requests are currently sent at? IIRC the limits we have are pretty generous, but depends on the use case of course.TASK DETAILhttps://phabricator.wikimedia.org/T178445EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpref
