fix(spanner): prioritize leader replica for read-write transactions in location-aware routing - #14195
Conversation
…n location-aware routing When experimental location-aware routing is enabled, read-write transactions starting with an inline begin (preferLeader=true) could be routed to follower replicas because operationUid > 0L on SQL requests caused selectTablet() to bypass the local leader and take the score-aware replica selection path. This change reorders the checks in KeyRangeCache.selectTablet() so that when preferLeader=true and a healthy local Paxos leader exists, the leader is selected directly. If the leader is unhealthy or in transient failure, it gracefully falls back to score-aware replica selection.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the tablet selection logic in KeyRangeCache.java by moving the score-aware selection block below the leader check, and adds corresponding tests in KeyRangeCacheTest.java. However, the refactoring incorrectly changes the conditional check for score-aware selection, bypassing it when preferLeader is false and no operation UID is present. The original !preferLeader condition should be preserved to maintain correct routing behavior.
| } | ||
| } | ||
|
|
||
| if (hintBuilder.getOperationUid() > 0L) { |
There was a problem hiding this comment.
By changing the condition from !preferLeader || hintBuilder.getOperationUid() > 0L to only hintBuilder.getOperationUid() > 0L, the score-aware tablet selection is bypassed when preferLeader is false and operationUid is 0 (or not set). This changes the routing behavior for non-leader-preferred reads, causing them to fall through to the sequential tablet loop instead of using score-aware selection. We should preserve the !preferLeader check here.
| if (hintBuilder.getOperationUid() > 0L) { | |
| if (!preferLeader || hintBuilder.getOperationUid() > 0L) { |
|
@rahul2393 can you take a look? |
|
Yes, I will check whether we need soft preference to leader or hard since hard can overload leader. |
2 participants
When experimental location-aware routing is enabled, read-write transactions starting with an inline begin (preferLeader=true) could be routed to follower replicas because operationUid > 0L on SQL requests caused selectTablet() to bypass the local leader and take the score-aware replica selection path.
This change reorders the checks in KeyRangeCache.selectTablet() so that when preferLeader=true and a healthy local Paxos leader exists, the leader is selected directly. If the leader is unhealthy or in transient failure, it gracefully falls back to score-aware replica selection.