The changes from 7d915a6 as part of SERVER-49895 made it so including {$_requestReshardingResumeToken: true} in the aggregation request would cause a {postBatchResumeToken: {ts: <latestOplogEntryTimestamp>}} to be included in the cursor response. However, the plumbing was only done in CollectionScan and therefore only applies when the pipeline can be entirely optimized away. PlanExecutorPipeline::_latestOplogTimestamp is only updated when PlanExecutorPipeline::_isChangeStream == true. This makes including {$_requestReshardingResumeToken: true} not useful when running more complex aggregations such as the one resharding is using to fetch donor shard's oplog entries.
Steps to reproduce
python buildscripts/resmoke.py run --suite=sharding jstests/sharding/resharding_oplog_sync_agg_resume_token.js
|
diff --git a/jstests/sharding/resharding_oplog_sync_agg_resume_token.js b/jstests/sharding/resharding_oplog_sync_agg_resume_token.js
|
index 047a01abc8..3dbeb5d4d3 100644
|
--- a/jstests/sharding/resharding_oplog_sync_agg_resume_token.js
|
+++ b/jstests/sharding/resharding_oplog_sync_agg_resume_token.js
|
@@ -28,7 +28,9 @@ const localDb = rst.getPrimary().getDB("local");
|
jsTest.log("Run aggregation pipeline on oplog with $_requestReshardingResumeToken set");
|
const resEnabled = localDb.runCommand({
|
aggregate: "oplog.rs",
|
- pipeline: [{$match: {ts: {$gte: Timestamp(0, 0)}}}],
|
+ // The $addFields prevents the pipeline from being optimized away as a simple plan executor.
|
+ // This is necessary to force the pipeline to be evaluated using PlanExecutorPipeline.
|
+ pipeline: [{$match: {ts: {$gte: Timestamp(0, 0)}}}, {$addFields: {extra: {$literal: "hi"}}}],
|
$_requestReshardingResumeToken: true,
|
cursor: {batchSize: 1}
|
});
|