[SERVER-33921] Revisit how the mongo shell decides whether it should retry a command or not Created: 15/Mar/18  Updated: 06/Dec/22

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

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Gantt Dependency
has to be done after SERVER-33218 Implement shell API for transactions Closed
Related
is related to SERVER-33789 Retryable writes shell machinery also... Closed
Assigned Teams:
Server Tooling & Methods
Backport Requested:
v4.0
Participants:
Story Points: 5

 Description   

The mongo shell currently bases its decision on whether it should retry a command or not on the command request having a "txnNumber" argument. Since the "find" and "getMore" command requests inside of a read-only or read/write transaction will also contain a "txnNumber" argument, we'll need to set a more explicit state on the mongo shell's session to indicate that the request it is about to perform should be retried.

let numRetries =
    (cmdObj.hasOwnProperty("txnNumber") && !jsTest.options().skipRetryOnNetworkError)
    ? 1
    : 0;



 Comments   
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 A. Jesse Jiryu Davis [ 04/Jan/19 ]

I suggest the shell should implement something close to the Drivers Spec we're designing in WRITING-3109.

Comment by Max Hirschhorn [ 30/May/18 ]

spencer, pavithra.vetriselvan, I've bumped this out of being MongoDB 4.0.0 GA required because I think the !driverSession._serverSession.isInActiveTransaction() check is good enough for now. I'm thinking of adding a special property (perhaps as a Symbol type) to the command request to indicate that we've assigned a transaction number from the retryable write codepath so we don't need to repeat the condition in both places.

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