The sharding catalog is not aware of unsharded collections. Usually, this means that operations against unsharded collections are forwarded unmodified from mongos to the primary shard, where the catalog metadata about unsharded collections resides. For $changeStreams, however, query execution machinery is always set up on both mongod and mongos, even if the collection being watched is not sharded. This is necessary to unsure an open change stream can continue to function if the unsharded collection ever becomes sharded.

It also means that when there is a merging part of a split pipeline executing on mongos for an unsharded collection, we have to lookup the default collation. Pipeline execution requires the default collation to be resolved in order to execute correctly, including the merging part of a change streams pipeline. This is done by running a listCollections against the primary shard:

https://github.com/mongodb/mongo/blob/a458c159eb3d3bf5260bbde38eeed22a45586636/src/mongo/s/commands/cluster_aggregate.cpp#L647-L672

The problem is that this logic is accidentally invoked for pipelines that run entirely on mongos, such as $listLocalSessions pipelines, or $currentOp with localOps:true. These pipelines should never need to contact the shards, but due to the logic above, they erroneously run listCollections against the primary shard.