[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:
Related
related to SERVER-34557 Allow running transactions against pr... Closed
Assigned Teams:
Server Development Platform
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:
Participants:

 Description   

I just ran into the following scenario:
1) Start a transaction
2) Do an update. This targets shard A.
3) Send a find command with readPreference: secondary. This targets the secondary of shard B.
4) NotMaster is returned with a TransientTransactionError.
5) The transaction gets retried over and over again with the same behavior.

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:

transactions may only read from the primary. If a read is attempted and the transaction’s read preference is not Primary drivers MUST raise an error containing the string "read preference in a transaction must be primary"

https://github.com/mongodb/specifications/blob/master/source/transactions/transactions.rst#readpreference

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 SERVER-34557.

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.

Generated at Thu Feb 08 04:55:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.