Overview

Revert commit 9c4ee3148de (SERVER-113969), which enabled findAndModify with a sort on unsharded tracked timeseries collections in 9.0.0-rc1. SERVER-131593 found that the sort is not actually applied, so the command can modify the wrong document. Reverting restores the pre-9.0 InvalidOptions error for findAndModify with sort on all tracked timeseries collections.

Details

The write path translates the filter to a bucket-level expression (canonical_delete.cpp / canonical_update.cpp), but the user's measurement-level sort and the top-k limit: 1 (set in parsed_writes_common.h) are planned untranslated against the buckets collection, where the sort field does not exist. Two failure modes were reproduced locally on a standalone:

1. Wrong document modified — with measurements sharing one bucket, findAndModify {query: {f: {$gt: 0, sort: {f: 1}

   , remove: true} }} removed the measurement with f: 300 instead of f: 100. All bucket-level sort keys are missing, so ordering degenerates to bucket _id (control.min.time) order.

2. Matching document silently missed — the limit: 1 truncates the plan to a single bucket. If the first-scanned bucket's control bounds cover the predicate but no measurement matches the residual filter, the command returns n: 0 even though a matching measurement exists in a later bucket.

The tests added by SERVER-113969 passed coincidentally: each test document had a distinct meta field (one bucket per document) and bucket ordering agreed with the expected sort order.

A proper fix requires measurement-level sort support in TimeseriesModifyStage (blocking top-1 selection across all matching buckets) and is tracked under SERVER-131593; sorts purely on the metaField could later be re-enabled cheaply by translating them to the bucket-level meta field.