Hi.

We are running redis on Azure and are noticing an issue, when some keys are incremented within a transaction successfully, even after they expected expiry.

i.e. I set a key to expire after 5s. It is still successfully incremented after 1h.

I've read this: https://redis.io/docs/manual/keyspace-notifications/#timing-of-expired-events

And it gave me an idea, that maybe our increment transaction does not trigger active expiration?

Are there any commands which do not trigger active expiration? Could transactions somehow interact with active expiration?

Thanks.

Comment From: hwware

Hi, Valdeminas,

I test the expire key in transaction in the latest verion, i do not find the issue you mention. Following is a simple test, let me know any extra requirement, Thanks. I set key a expired in 10 seconds.

Redis [QUESTION] What counts as Active expiration commands?

Comment From: Valdeminas

Thanks for the reply.

As I mentioned, this only happens sometimes, so not sure if it will be possible to replicate it on demand.

Do you have any other ideas, what might cause this behaviour?

Not sure what you mean by “extra requirement” - could you expand?

Thanks.

Comment From: hwware

Thanks for the reply.

As I mentioned, this only happens sometimes, so not sure if it will be possible to replicate it on demand.

Do you have any other ideas, what might cause this behaviour?

Not sure what you mean by “extra requirement” - could you expand?

Thanks.

Hi I have no idea why it happens, but the extra requirement means if you could provide your Redis version, and under which operating systen is better.

You know, for some issues which are not easily reproduced, it is hard to find the cause, Thanks

Comment From: oranagra

@Valdeminas which version of redis do you use? which commands are involved? any failovers or replicas involved?

Comment From: Valdeminas

@oranagra Hi. We are running Redis 6.0.14 on Azure.

I have looked into the matter a little bit further and it seems, that even though I specify the expiration, sometimes key are set without it.

Since it's managed by Azure, I am not sure about failover or replica settings :/

Comment From: Valdeminas

A bit more info

# Server

redis_version:6.0.14

redis_mode:standalone

os:Windows  

arch_bits:64

multiplexing_api:winsock_IOCP

Comment From: oranagra

Well, it is clear that this is a modified version of redis (we don't support WIndows), so it's hard to say if maybe the changes could cause that. Additionally, there could be some issues with replication and failovers, to which we are in the dark. So, without reproducing this on a vanilla version of Redis, there's not much we can do.

It may help if you post some details about the commands you use, how you set the expiration, maybe using WATCH-MULTI-EXEC? so that maybe someone can come with a theory of what replication / failover scenario can maybe cause the TTL to get lost.

Comment From: Valdeminas

@oranagra Thanks for your help. Will continue investigating this.

Comment From: Valdeminas

Just a quick update.

Rewrote our code to evaluate the following script

@"local current current = redis.call('incr',@key) if current == 1 then redis.call('pexpire', @key, @timeout) end return current"; And the issue now seems to be fixed.