The problem/use-case that the feature addresses

Need to have counters self-delete after a certain period.

Description of the feature

Allow the typical EX, etc. options on INCR and DECR queries.

Alternatives you've considered

Issuing two separate INCR|DECR, EXPIRE commands. But this can introduce race conditions compared to using a single query.

Comment From: madolson

You can multi-exec an INCR + expire command. That shouldn't introduce race conditions. Although we have been adding more commands/options, I'm not really convinced this is a common enough use case to warrant adding a special flag for. Happy to hear other thoughts though.

Comment From: itamarhaber

Also see: https://github.com/redis/redis/issues/4565

I'm agreeing w/ @madolson, although: 1) The other string command does have an EX flavor (SETEX) 2) String counters are a common pattern afaik, so expiring them makes sense in a cache deployment 3) One should not forget (INCR|DECR)BY[FLOAT] while dwelling on this 4) From a cursory glance, adding the EX subcommand to all these doesn't seem like breaking the API

Comment From: gkorland

@mcandre can you please extend on your use case? Why would you like to extend the TTL on INCRBY? Is that a way to keep the "hot" key in Redis? Isn't that just another LRU mechanism?

Comment From: oranagra

@gkorland i don't think he wants to increment the expiration time.. he wants to set the expiration time when incrementing a counter.

I don't think we wanna ad an EX option to all the commands (should be achieved with MULTI-EXEC and pipeline). IIUC the reason SET has it, is because it's a very common case for caching. Although counters are also strings, to my understanding they won't be used in caching in that way (would be set with SET, not with INCRBY)

Comment From: itamarhaber

Sort of duplicate of #4423

Comment From: RandyLambert

@gkorland i don't think he wants to increment the expiration time.. he wants to set the expiration time when incrementing a counter.

I don't think we wanna ad an EX option to all the commands (should be achieved with MULTI-EXEC and pipeline). IIUC the reason SET has it, is because it's a very common case for caching. Although counters are also strings, to my understanding they won't be used in caching in that way (would be set with SET, not with INCRBY)

In my opinion, this is a very commonly used function. When using redis, our company sometimes incr a value, which expires after not operating for a certain time. Now to implement this function, we need to use lua or execute two commands, which is very inconvenient

Comment From: RandyLambert

Our company often uses this feature. If I add Expiration Setting to Incr/DECR, will it have the opportunity to merge to the Redis main branch?