[SERVER-47932] doNotSetMoreToCome failpoint should end isMaster streams Created: 04/May/20  Updated: 12/Dec/23

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

Type: Task Priority: Major - P3
Reporter: Shane Harvey Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-47045 Add tests to check that mongos marks ... Closed
Assigned Teams:
Cluster Scalability
Sprint: Service arch 2020-05-18
Participants:

 Description   

Drivers intend to use the doNotSetMoreToCome failpoint added inĀ SERVER-47045 to test the following behavior in the streaming protocol:

If the response is successful (includes "ok:1") and does not include the OP_MSG moreToCome flag, then the client initiates a new awaitable isMaster with the topologyVersion field from the previous response.

Essentially we want to assert that the Monitor reinitiates a new isMaster stream and never marks the server Unknown. The doNotSetMoreToCome failpoint seems to correctly disable the moreToCome flag but it does not end the stream. So the server will continue sending exhaust responses which violates the OP_MSG protocol. The driver will notice the protocol error and mark the server Unknown (thus failing the test).

I believe the failpoint needs to end the server's isMaster stream at the same time that it removes the moreToCome flag.



 Comments   
Comment by Janna Golden [ 06/May/20 ]

Cool, I agree. Sounds good!

Comment by Tess Avitabile (Inactive) [ 06/May/20 ]

I think it has to be an invariant, since I don't know how to write a test that something never happens. We can add a comment saying that this is allowed by the protocol, but removing the invariant requires adding drivers test coverage. Thanks, janna.golden!

Comment by Janna Golden [ 06/May/20 ]

Sure, I think an invariant might be more useful than a test but I could also see an invariant being too strong since technically the protocol allows it - tess.avitabile, let me know if you agree/disagree? I'm happy to add the test or invariant and remove the existing failpoint as a part of this ticket once we decide.

Comment by Shane Harvey [ 05/May/20 ]

Update: janna.golden and tess.avitabile both agree that the server will never send ok:1 with moreToCome:false in response to a streaming isMaster. The server will only ever end the isMaster stream by closing the connection or by returning ok:0 with moreToCome:false. They recommend we remove this failpoint because it is covers behavior that does not exist in practice.

Given this new decision, is it possible to add a server test (or invariant) that ensures ok:1 with moreToCome:false is never sent in response to a streaming isMaster (awaitable isMaster + OP_MSG exhaust)?

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