The throttle_success method of SimpleRateThrottle updates the cache with a new value of history. If there are a number of concurrent requests, there may be a race condition where certain values of history would be overwritten by stale data.

Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

• Able to reproduce the issue with LocMemCache and memcached
• Enable throttling on a simple view & set the rate to say 500/hour
• Send concurrent requests with ab, e.g.
  Setup 1 : ab -l -c 20 -n 500 http://127.0.0.1:8000
  Setup 2 : ab -l -c 1 -n 500 http://127.0.0.1:8000

Expected behavior

• In both setup (1 & 2), the view should be throttled for any further request because of the 500 requests sent by ab (once in batches of 20 & second time as a single request).

Actual behavior

• Setup 1 : View is not throttled yet (possible another 20-50 requests can be served, varies each time).
• Setup 2 : View is throttled for any subsequent request. Concurrency is 1, so history is recorded correctly in the cache.

It appears as though some concurrent requests are being ignored by the cache.