Add support for SORT_RO by slorello89 · Pull Request #2111 · StackExchange/StackExchange.Redis

@slorello89

NickCraver

NickCraver

NickCraver

Co-authored-by: Nick Craver <nrcraver@gmail.com>

@slorello89

NickCraver

@slorello89

We can skip feature detection when it won't matter here :)
This can be a cleaner switch expression these days, yay!

@NickCraver

These were hitting the primary so we weren't really exercising what we wanted to here for sure - made some tweaks to make damn sure we're testing what we think we are :)

@NickCraver NickCraver changed the title SORT_RO Add support for SORT_RO

Apr 20, 2022

@NickCraver

@NickCraver

NickCraver

NickCraver added a commit that referenced this pull request

Jul 18, 2022
…primary-only out of primary-only (#2183)

Fixes #2182 

@NickCraver for background in #2101, we changed some of the logic around primary-only to require all commands to be explicitly stated as primary-only or not. During this effort, I went through the command list and checked to see which were considered write commands (which would be rejected by a replica) so that there would be consistency in behavior when stumbling on commands that would ordinarily be rejected by a replica. This made a slightly more restrictive list of commands. 

Enter #2182, where this inconsistency had evidently become load-bearing. The user has evidently designated their replicas as writeable (I think I was subconsciously aware of this capability but have never actually seen anyone use it). As it turns out By resolving this inconsistency in #2101 and the follow-on issue when I introduced `SORT_RO` in #2111 I apparently introduced a break.

This PR reverts all the pre-2.6.45 commands' primary vs replica disposition back to their previous state which will remove the break. Any command that was introduced in 2.6.45 is correctly dispositioned.

Co-authored-by: Nick Craver <nrcraver@gmail.com>