For all time-series collections, sharded or unsharded, in a sharded cluster, we need to run retryable updates through the clustered version of the internal transaction API to ensure atomicity. This means we need to make this decision on mongos and initiate the transaction there. But currently, we don't track unsharded collections, time-series or non-time-series, in the sharding catalog.

Running a retryable time-series update on an unsharded collection in a sharded cluster now will fail because the command simply gets routed to the primary shard without running in a transaction and uses the replSet version of the transaction API on mongod. The mongod will then return the error:

"Transaction API does not currently support use within operations with shard or database versions without using router commands"

After SERVER-81495, in a sharded cluster, we will check if a collection, sharded or unsharded, is time-series, and always use the sharded version of the internal transaction API to run retryable time-series updates.

Alternatively, we might make the shard to run the clustered version of the internal transaction API. This makes the mongod to act as the router, which would be quite complicated to debug and reason about.

Another potential temporary workaround is to make the shard to return an error to the router to make it retry the command in a transaction (a two-phase approach).

Both of these workarounds can be removed completely once SERVER-81495 is done.