We can make a scenario that s0 and s1 have artificially different ideas of collection routing info on the same time-series collection. The scenario in interest is like this, assuming that we have two mongos [s0, s1].

1. Creates a sharded timeseries collection with two shards and inserts some documents into it on s1
2. Drops the same collection and create an unsharded timeseries collection and insert some documents into it on s0. The s1 still thinks that the same collection is a sharded timeseries collection

At this point, if we run a two-phase deleteOne or findAndModify on s1, we get an error NamespaceNotSharded: Expected collection timeseries_arbitrary_writes_multi_mongos.system.buckets.ts to be sharded from the first phase (cluster query) of the two-phase protocol. This might be because s1 thinks that the collection is a sharded time-series collection but it is actually unsharded.

Update: Repurposed this ticket to add test cases for findAndModify & deleteOne on 1) unsharded to sharded case and 2) sharded to unsharded case.

Original title:
Outdated collection routing info for time-series deleteOne without shard key with multiple mongos