Will timeouts be considered to adding to the repo?

[chowchow316]

I found that timeout are not implemented, is there any plan to implement it? And is there any technical challenge in the implementation? Do you accept the contribution from outside?
Thank you!

[alicebob]

The primary use case for miniredis is unittests, in which case timeouts are not wanted. I do want to test if timeouts are set correctly, but the timeouts shouldn't trigger. So I prefer to keep them as is.

What's your use case for the timeouts?

[chowchow316]

Thanks for your reply. Currently I'm using Redis to implement a rate-limiting service, and trying to cover all the functionalities by unittests. And till now, only the expire part cannot be covered when using miniredis as a mock. Do you have any suggestions?

[alicebob]

I see you point, I'll think about it. It would certainly be optional behavior.

[chowchow316]

Yes, and I'm thinking about adding this feature in my fork, my current idea is to add a periodic timer to trigger key deletion in the DB. How do you like it?

[alicebob]

The more I think about it the more I would make a sort of fast-forward, time-machine function. You call it with a duration, and all TTLs timeouts will be decreased by that much, and any expired keys will be deleted. In this way you then have full control in your tests over how 'fast' time goes. You can do things like:

<set redis keys with ttl of 7 days>
db.FastForward(24 * time.Hour)
<check that things didn't expire yet>
db.FastForward(6 * 24 *time.Hour)
<check that things expired>

Or you can call it in a quick loop in your test, if you want more real-time like behavior. I think having a system which is paused by default and only moves when you tell it to should work good for testing. And as a bonus you won't need to call time.Sleep() in your tests, which keeps them speedy and simple.

Some things to consider:

• The TTL values are currently simple integers, and sometimes they are seconds, and sometimes they are milliseconds. You might want to add another map which keeps things as proper durations
• Redis used to support absolute timestamps as TTLs, maybe that should simply not be supported here?
• Maybe it is nicer to work with absolute times, and not with durations. Not sure.

How about this way, Sun?

[chowchow316]

Hi Harmen, I like the idea of time machine, and for mock redis, the time manipulation be as flexible as possible. And If I understand your idea correctly, it should be somewhat like #14 (could you help to review it? Thanks! ).
Furthermore, there should also be a FastForward in miniredis.go, so that when people writing unittest they can call the function and manipulate time as they want.

Regarding your concerns, I think for unit test, durations should work fine. And I agree that TTL values can be extended with units (seconds, milliseconds, etc).

[alicebob]

Looks good as the general idea. Would it be useful this way in the mixer project?

[chowchow316]

Thanks, and yes, it is useful for the unit test of our redis-based rate-limiter. And would you like to merge the PR in? If so, I will make it more complete.

[alicebob]

Yeah, I would like to merge it.

[chowchow316]

Awesome, I will update the PR, and your comments would be a lot of help.

[alicebob]

I pulled your branch into the ttl branch from #15, and made some more small improvements to the expire handling.

Does this now work for you? If so I'll merge this into master and call it 2.0.

[alicebob]

It's merged, let me know if there are any issues!

[alicebob]

And thanks for the help!

[chowchow316]

Yes, it looks great! Thank you!