[SERVER-40473] Using readPreference: secondary in multi-statement transaction returns NotMaster error with TransientTransactionError label Created: 04/Apr/19 Updated: 19/Jun/23 Resolved: 19/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matthew Saltz (Inactive) | Assignee: | [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | sdp-backlog-purge | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Server Development Platform
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Steps To Reproduce: | |||||||||
| Participants: | |||||||||
| Description |
|
I just ran into the following scenario: Our docs for readPreference say "Multi-document transactions that contain read operations must use read preference primary." (https://docs.mongodb.com/manual/core/read-preference/) but given the above scenario, I'm wondering if we should do better and instead have the router throw some different, non-transient error if it notices that a statement in a multi-shard transaction is sent with readConcern: secondary. Alternatively the router could always upgrade the readPreference to be primary for commands running in a transaction. |
| Comments |
| Comment by Alex Neben [ 19/Jun/23 ] |
|
This has been identified as work that the SDP team won't do in the near term. Please reopen with a comment if you feel this work should be reprioritized and explain why. |
| Comment by Steven Vannelli [ 10/May/22 ] |
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. |
| Comment by Mira Carey [ 13/Feb/20 ] |
|
We believe this to be a bug in the driver in the shell that was added when the shell gained transaction support |
| Comment by Gregory McKeon (Inactive) [ 16/Apr/19 ] |
|
Re-triaging, since we now know this is a shell bug. |
| Comment by Shane Harvey [ 16/Apr/19 ] |
|
Looks like a bug in the shell. The transaction spec only allows primary read preference in a transaction:
This behavior is tested here so we know that all drivers raise a client side error when attempting to read with a non-primary read preference. Please don't change the server to reject non-primary read preferences as that would repeat the regression fixed in |
| Comment by Matthew Saltz (Inactive) [ 16/Apr/19 ] |
|
shane.harvey I was discussing this today with Andy and Aly and they thought that this may actually be a bug with the shell (which was being used when I encountered this issue), and that drivers normally handle this scenario already in a way that's reasonable. Do you know what the ordinary driver behavior is when a user sends readPreference: secondary for a command within a multi-statement transaction? |
| Comment by Matthew Saltz (Inactive) [ 09/Apr/19 ] |
|
I believe the actual assert is coming from here, in service_entry_point_common, due to this check that makes sure multi-document transactions can't run on secondaries. The TransientTransactionError label then is attached here when the aforementioned assert fails. getErrorLabels calls into isTransientTransactionError which determines that a NotMaster error is indeed a TransientTransactionError. |