A shard acting as a sub-router for a transaction, will have checked out the session on the command entry point and attached the associated TransactionRouter object to the opCtx. As also reported on SERVER-107535, some of the TransactionRouter state, including atClusterTimeForSnapshotReadConcern and placementConflictTimeForNonSnapshotReadConcern, is not set to be consistent with the current transaction until TransactionRouter::_resetRouterStateForStartOrContinueTransaction - that state is left as it was in the previous transaction in the session. Typically sub-routers do that on multi_statement_transaction_requests_sender when they are about to dispatch a message to another transaction participant.

However, TransactionRouter is consulted before that happens. For instance, to determine the clusterTime at which to interpret the RoutingTable used to decide what shards to target for the inner lookup query. That causes the query to be router according to a routing table that does not correspond to the clusterTime at which the transaction is executing, which can cause query results to be incorrect.

Note that this does not affect v8.0 and earlier, since on these versions the opCtx’s ReadConcernArgs::atClusterTime takes precedence over the TransactionRouter::atClusterTime. SERVER-104395 changed that order.