fix: don't reset expiration when TTL is zero

[david-quennoz-reup]

It seems to be possible for PTTL to return zero when a key is really close to expiring but not actually there yet. When this happens the increment script would reset the key's expiration while the count rolls over into the new window, possibly causing clients to be rate limited at lower request rates or for longer periods of time than they should.

The likelihood of this happening is probably low for most use cases, but I have one high-load global rate limit in my app that regularly sees its window bug out to be twice (and sometimes even thrice) as long as it should be.

Just changing the the comparison from <= to < has fixed this is my app. I believe its a safe change as PTTL explicitly returns -1 if the key doesn't yet have a expiration.

Thanks for the great package btw!

[nfriedly]

Hey, thanks!

I'm traveling and probably won't be able to give this a close look for a few days, but I'll try to remember to come back to this once I'm home. (Or @gamemaker1 might get to it before me.)

One thought that crossed my mind: do you think you could make a test that recreates the error situation from before the fix and behaves correctly after?

[gamemaker1]

Thanks for this PR @david-quennoz-reup! I think the change is good, and all the library tests are passing so it shouldn't break any existing rate limiters.

I do agree with @nfriedly, it would be better to merge this change along with a test for this case.