ERR wrong number of arguments for 'expire' command - Azure Cache for Redis

[TheCakeMonster]

I'm getting an exception thrown from an Azure Functions app when trying to set the expiry on a key associated with a set in Azure Cache for Redis.

"ERR wrong number of arguments for 'expire' command"

The following all fail against Azure Cache for Redis:
await database.KeyExpireAsync(key, TimeSpan.FromHours(48), ExpireWhen.HasNoExpiry);
await database.KeyExpireAsync(key, TimeSpan.FromHours(48), ExpireWhen.HasNoExpiry, CommandFlags.DemandMaster);
await database.KeyExpireAsync(key, DateTime.Now.AddHours(48), ExpireWhen.HasNoExpiry);
await database.KeyExpireAsync(key, DateTime.Now.AddHours(48), ExpireWhen.HasNoExpiry, CommandFlags.DemandMaster);

However, the following works:
await database.KeyExpireAsync(key, TimeSpan.FromHours(48));

This problem seems to be specific to Azure Cache for Redis - all of the above work fine against a local Redis container. Therefore, I don't think we can reasonably lay the blame at the door of StackExchange.Redis. There might be nothing we can do to fix it. Mainly, I'm reporting it because I can't find anyone else having written about the problem, or the solution - which is that it only seems to accept calls using overloads with just 2 parameters.

Running the INFO command against the cache in Azure reports that it is running Redis 6.0.14. However, I suspect it might be a lightly customised version of Redis that Microsoft makes available in Azure.

We use several cache sizes/SKUs in Azure, they all seem to suffer from the same problem. C0 and C1 caches both seem to demonstrate the same problem/limitation, for example, and more besides.

I hope this is useful to someone, even if it gets closed without redress.

[philon-msft]

Support for the "ExpireWhen" arg ([NX | XX | GT | LT]) wasn't added until Redis 7.0.0 (see https://redis.io/docs/latest/commands/expire/)

[TheCakeMonster]

Ah, so it was. Thanks, yes that explains it. I didn't know there had been any changes in this area. Since the command has been around for such a long time, I never even considered it. DOH!

Is there any desire to have StackExchange.Redis change its behaviour based on Redis version? If so, it's not doing that in this regard, and I'll leave the issue open. However, if there is no desire for it to be backwards compatible and adapt its behaviour to suit older versions then we can instead close this.

[mgravell]

To adapt to the server version, we would have to go down the route of Lua or MULTI/EXEC; both of these IMO add unexpected complexity, so I'd rather just leave it as-is. I'm also averse to blind server-version checks, because it is sometimes the case that "not quite redis" servers implement features that their reported server version doesn't.

[TheCakeMonster]

Thanks Marc, understood. I'll close this, then.