[AsadIqbal-Dev]

Fixes #2821

A few methods pick a server up front, through RedisBase.GetFeatures, to decide which command to send:

• KeyDelete (DEL vs UNLINK)
• KeyExpire with sub-second precision (PEXPIRE)
• LockExtend (SET IFEQ)
• LockRelease (DELEX)

GetFeatures passed the caller's flags straight to SelectServer, so with PreferReplica it picked a replica. The message itself is upgraded to DemandMaster by Message.SetPrimaryOnly, but because the replica was passed in explicitly, the send failed with Command cannot be issued to a replica. Commands that pick their server when the message is sent, like StringSet, already went to the primary, which is the difference the issue describes.

GetFeatures now applies the same rule as Message.SetPrimaryOnly for primary-only commands: PreferMaster/PreferReplica become DemandMaster before selecting. DemandReplica is left alone, so it still fails the way it does for every other primary-only command. RedisServer overrides GetFeatures and isn't affected.

Test: KeyTests.PrimaryOnlyCommandsWithPreferReplicaRunOnThePrimary runs against the primary/replica pair and calls each method, sync and async, with PreferReplica. I ran CI on my fork. Without the fix, the test fails on RESP2 and RESP3 with Command cannot be issued to a replica: PEXPIRE .... With the fix, the Ubuntu job passes.

Checklist

• I fully and freely contribute this code in accordance with the project license (and am legally able to do so)
• I take responsibility for this contribution's quality and correctness, including any portions produced with AI assistance (see CONTRIBUTING.md).

[mgravell]

Makes perfect sense at a glance. I'll look at it in more detail tomorrow, thanks!

[mgravell]

Looks good, thanks. I pushed one small commit onto your branch (fd37aec) rather than round-tripping two nits:

• GetFeatures now tests != DemandReplica instead of is PreferMaster or PreferReplica, so it is literally the same rule as Message.SetPrimaryOnly (which also upgrades None via its default arm); the comment now points at that method.
• A comment in the test explaining that the fractional-second expiry is what forces the PEXPIRE path.

No behaviour change from your version. Will merge once CI is green.