For queries on sharded views, we do the optimization on the pipeline twice. The first time, when the query is sent on the view definition to the primary shard, and the second time when the query is send on the base collection (after the kickback to mongos). For normal views, this is ok, because the pipeline optimizations are generally idempotent. But the DocumentSourceInternalUnpackBucket::doOptimizeAt() may not idempotent. There are known issues (like SERVER-60373), where this function generates duplicates stages. We should use this ticket to evaluate any other potential issues with running the function twice and address them.