Implement locking to prevent race conditions

[Sammyjo20]

Currently, I haven't implemented any form of atomic locks into the rate limiter stores. I would like to know how difficult this is, and how to implement it. For the Redis/Predis ones I could implement a similar Redis locking functionality that Laravel does - and for the file store I could use flock function in PHP.

I wonder if I could do something like this:

1. In the initial onRequest middleware, we get the limiter from the store like usual

Then before we save the latest number of hits:

2. Grab the limiter again
3. Aquire the lock and then update the limiter within the store

[larskoole]

Hey, just wanted to say I love Saloon and I'd be very interested in this feature. Without atomic locks this plugin is not built for scale (which is why most people use the plugin haha).

If you ever decide to pick this up again: I think you should obtain the lock before doing the request, then update the limiter with a hit, and save it before doing the request. If anything happens before the request has been sent you could obtain the lock again to decrease the limiter hit by one but I'd see that as optional since it could be possible that you don't obtain the lock instantly. The "anticipation hit" should prevent any duplicate requests the package is now experiencing (at scale).