[SERVER-31134] Adapt change stream tests to relax assertions on change visibility Created: 18/Sep/17  Updated: 30/Oct/23  Resolved: 04/Oct/17

Status: Closed
Project: Core Server
Component/s: Aggregation Framework, Querying
Affects Version/s: None
Fix Version/s: 3.6.0-rc0

Type: Task Priority: Major - P3
Reporter: Charlie Swanson Assignee: Judah Schvimer
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-31276 Ensure change_streams_mongos_passthro... Closed
Related
related to SERVER-32175 change_stream_collation.js should use... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2017-10-02, Repl 2017-10-23
Participants:

 Description   

Many of the tests in the change stream suite do something like this:

jstests/change_streams/change_streams.js

83
    cursor = startWatchingChanges([{$changeStream: {}}], db.t1);
84
    assert.writeOK(db.t1.insert({_id: 1, a: 2}));
85
    expected = {
86
        _id: {
87
            documentKey: {_id: 1},
88
            uuid: t1Uuid,
89
        },
90
        documentKey: {_id: 1},
91
        fullDocument: {_id: 1, a: 2},
92
        ns: {db: "test", coll: "t1"},
93
        operationType: "insert",
94
    };
95
    assertNextBatchMatches({cursor: cursor, expectedBatch: [expected]});

To add some commentary, the problematic pattern is:

  1. Open a change stream
  2. Do some write
  3. Assert that write is visible in the next getMore for that change stream.

These tests are okay to run against a replica set or an unsharded collection through mongos, but do not work against a sharded collection. A change stream running against a sharded collection cannot always see changes in the next batch, because it needs to return changes in order of their cluster time, and so can't immediately return results from one shard without getting a guarantee from another shard that it won't return things ahead of that one.

In case that was confusing - here's an example:
Suppose there are two shards, and we just inserted a document to shard 1. mongos's change stream cursor will see that change, and see that it happened at time T1. It wants to return that change, but it is paranoid that the cursor on shard 2 might come back with a change at time T0 (< T1) that would have to come first. So it waits to hear back from shard 2. Shard 2 might not respond for a while, particularly in a test when there aren't any writes happening. We do know that shard 2 will eventually respond with an updated timestamp due to the periodic noop write that is going on in the background.

So, in order to re-use the tests in the jstests/change_streams directory, we need to convert assertions like the one above into a style more like:

  1. Open a change stream cursor
  2. Do a write
  3. assert.soon that getMores on that cursor will eventually return that change.

When we eventually enable a passthrough that runs with sharded collections, we will need to be sure the periodic noop write is happening (it's disabled by default in ShardingTest, I'm not sure about through resmoke.py) - and should consider making the frequency configurable, rather than the default 10 seconds.



 Comments   
Comment by Githook User [ 04/Oct/17 ]

Author:

{'email': 'judah@mongodb.com', 'name': 'Judah Schvimer', 'username': 'judahschvimer'}

Message: SERVER-31134 Adapt change stream tests to relax assertions on change visibility
Branch: master
https://github.com/mongodb/mongo/commit/5180b8e6272169f1f8f237f1d64fe57f690b4802

Comment by Matthew Russotto [ 19/Sep/17 ]

Don't need to worry about this one:

report_latest_observed_oplog_timestamp.js

It is not run on sharding because it's testing a detail of mongos/mongod communication.

Comment by Charlie Swanson [ 18/Sep/17 ]

cc spencer, I think we said judah.schvimer might have time for this?

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