[SERVER-47508] opCtx->inMultiDocumentTransaction() is set to true for test case run "outside" of a transaction Created: 13/Apr/20  Updated: 27/Oct/23  Resolved: 27/Apr/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Maria van Keulen Assignee: Backlog - Replication Team
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-51352 Complete TODO listed in SERVER-47508 Closed
is related to SERVER-47444 Assertion to guard against individual... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

In this test case, we attempt to run a command “outside” of a transaction. This test case currently reaches the branch where we set inMultiDocumentTransaction to true on the OperationContext, since it's a case where we specify txnNumber and autocommit=false.

Eventually, the test case will fail this validation, but until then, opCtx->inMultiDocumentTransaction is true.

It seems to be a bug that opCtx->inMultiDocumentTransaction is true even though the test case should eventually fail with NoSuchTransaction.



 Comments   
Comment by Siyuan Zhou [ 27/Apr/20 ]

The semantics of opCtx->inMultiDocumentTransaction() works by design as explained above.

The transaction test case allows more error codes that could only occur in passthrough test cases that specify read concerns. We could avoid attaching read concerns in those cases, but the risk of relaxing the error codes seems minimal to me.

Comment by Siyuan Zhou [ 14/Apr/20 ]

Since we moved the code to check whether a read concern is given without startTransaction in transactions earlier in SERVER-47444, it returns an InvalidOption error earlier before the expected NoSuchTransaction error in the linked test case. causally_consistent_jscore_txns_passthrough encounters this error.

I don't think the server behavior is a problem since when a command violates two checks, returning an error for either one seems fine to me. If we want to make the test more consistent, we could change the passthrough tests not to attach read concerns on transaction statements without startTransaction.

opCtx->inMultiDocumentTransaction() is designed to represent whether the users requested a transaction. The command could fail with NoSuchTransaction error later. However, after parsing, validation and transaction unstash, opCtx->inMultiDocumentTransaction() guarantees the transaction is open for command execution.

Thus, I'd propose to focus on fixing the passthrough test in this ticket if we think it's necessary.

Comment by Maria van Keulen [ 13/Apr/20 ]

This issue came up during SERVER-47444, which moves this assertion prior to the aforementioned validation. As a result, the linked test case fails with InvalidOptions instead of NoSuchTransaction in suites that add a readConcern to this invocation, since the new readConcern check relies on the value of opCtx->inMultiDocumentTransaction().

I chatted with samy.lanka about this, and for now we believe it makes sense to allow the test case to accommodate both errors, and modify the wording of the test case.

Generated at Thu Feb 08 05:14:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.