In a process running with an embedded router, the router and shard roles will share a TransactionRouter object because the TransactionRouter is a decoration on the Session which is shared across both. In a world without embedded routers, we expect that a router who has not participated in a given transaction knows nothing about that transaction. But now, if the shard acted as a sub-router for a given transaction, the embedded router will have access to state about the transaction.

This is mainly a problem if a client starts a transaction on one router, but then later runs the recovery protocol through an embedded router on a process where the shard role had acted as a subRouter in the transaction being recovered. A TransactionRouter object which is a sub-router should not be allowed to run the commit or abort protocol because a sub-router will not know of all of the participants, but a TransactionRouter running on an embedded router role should be allowed to run the recovery commit protocol, even if the shard role on that process acted as a sub-router. However today, if a shard acts as a sub-router in a transaction, it creates a TransactionRouter object and sets a flag subRouter on it. If commit or abort are called on this TR object when the subRouter flag is set, the TR will fail the commit or abort. So, if a client tries to recover a commit decision through an embedded router that is running on a process where the shard acted as a sub-router, we’ll fail that request.

We should make it so that a router and shard role do not share a TransactionRouter object.