[SERVER-44508] Add maxAwaitTimeMS and topologyVersion to isMaster command Created: 08/Nov/19  Updated: 29/Oct/23  Resolved: 22/Nov/19

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

Type: New Feature Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Haley Connelly
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-44509 Make isMaster wait for up to maxAwait... Closed
Documented
is documented by DOCS-13381 Investigate changes in SERVER-44508: ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-11-18, Repl 2019-12-02
Participants:

 Description   

Also return a dummy topologyVersion field in the isMaster reply.



 Comments   
Comment by Githook User [ 22/Nov/19 ]

Author:

{'name': 'Haley Connelly', 'username': 'haleyConnelly', 'email': 'haley.connelly@10gen.com'}

Message: SERVER-44508 Add maxAwaitTimeMS and topologyVersion to isMaster Command
Branch: master
https://github.com/mongodb/mongo/commit/c72849fb005cfcba272eb53b6024d5fd31c3ec9c

Comment by Tess Avitabile (Inactive) [ 14/Nov/19 ]

As part of this ticket, I think we can also parse maxAwaitTimeMS and topologyVersion and validate their types. This will allow us to use the fields in SERVER-44509 and SERVER-44514.

Comment by Haley Connelly [ 14/Nov/19 ]

Currently, our isMaster command can take in arbitrary parameters without failing in our integration tests.

eg) db.runCommand(

{isMaster: 1, maxAwaitTimeMS: 1}

) does fail or appear to yield any telling errors. For this reason, I believe that the scope of this ticket is now limited to introducing the dummy TopologyVersion field to the isMaster reply.

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