[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: |
|
||||||||
| Assigned Teams: |
Cluster Scalability
|
||||||||
| Sprint: | Service arch 2020-05-18 | ||||||||
| Participants: | |||||||||
| Description |
|
Drivers intend to use the doNotSetMoreToCome failpoint added inĀ
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)? |