-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Aggregation Framework, Replication, Sharding
-
Fully Compatible
-
ALL
-
v4.0, v3.6
-
Query 2018-04-23, Query 2018-05-07, Query 2018-05-21, Query 2018-06-04
-
26
Taken from a comment on SERVER-32029:
If a collection is sharded but not present on all shards, then some shards will not know about the collection, and will also mistakenly error upon resuming because of this. This bug is actually harder to fix, because it's hard to know whether the collection doesn't exist because it was dropped, or whether it doesn't exist because you don't own any chunks for it.
- causes
-
PYTHON-1582 Test Failure - TestChangeStream.test_aggregate_cursor_blocks and test_next_blocks
- Closed
- depends on
-
SERVER-32190 Make a MongoProcessInterface available to all stages, not just those that subclass DocumentSourceNeedsMongoProcessInterface
- Closed
-
SERVER-34695 Move aggregation retry logic to command processing layer
- Closed
- is depended on by
-
SERVER-34710 Add test for resuming a change stream after an "invalidate" from a dropCollection
- Closed
- is related to
-
SERVER-35254 Resuming a change stream on a stale mongos with a valid resume token may incorrectly fail
- Closed
- related to
-
SERVER-32029 ChangeStream resumeAfter does not work on unsharded collections if there is more than one shard in the system
- Closed
-
SERVER-43475 Complete TODO listed in SERVER-32088
- Closed
-
SERVER-44210 Complete TODO listed in SERVER-32088
- Closed