Hello!
This line says to me that by calling the Limiter.prototype.get method, an entry will always be added during the computation of the the count, and more importantly, the returned remaining values.
In laymen's terms, it seems like the caller is "charged" a count value, even when ultimately the limiter willmay tell them that they have zero remaining. This can result in the goalpost continuing to move for an impolite/naive caller. This may be what we want, but it may not be. A poorly written caller script may end up perpetually waiting.
It would be nice if there were a way to only add the element to the array if remaining > 0.
I'm not a Redis expert, but I realize that the commands are issued within a MULTI transaction, and recognize the benefits there that it may not be a good idea to only perform the ZADD if we think there are "tokens" remaining (due to concurrency realities). Perhaps:
- Some crazy if/else can be done in the Redis commands that only calls
ZADD if the ZCARD length was below the max?
- Maybe some of the
ZADD options can support something useful with this idea?
- Perhaps if the result is that the
remaining <= 0, then element added by ZADD is removed in a subsequent Redis command? We know the element we created, right? This may open the user up to slightly race-vulnerable conditions (or not) that they can decide if they are OK with?
Seems semi-related to:
#43
and
#45
Hello!
This line says to me that by calling the
Limiter.prototype.getmethod, an entry will always be added during the computation of the thecount, and more importantly, the returnedremainingvalues.In laymen's terms, it seems like the caller is "charged" a
countvalue, even when ultimately the limiterwillmay tell them that they have zeroremaining. This can result in the goalpost continuing to move for an impolite/naive caller. This may be what we want, but it may not be. A poorly written caller script may end up perpetually waiting.It would be nice if there were a way to only add the element to the array if
remaining > 0.I'm not a Redis expert, but I realize that the commands are issued within a
MULTItransaction, and recognize the benefits there that it may not be a good idea to only perform theZADDif we think there are "tokens" remaining (due to concurrency realities). Perhaps:ZADDif theZCARDlength was below themax?ZADDoptions can support something useful with this idea?remaining <= 0, then element added byZADDis removed in a subsequent Redis command? We know the element we created, right? This may open the user up to slightly race-vulnerable conditions (or not) that they can decide if they are OK with?Seems semi-related to:
#43
and
#45