Today we don't unset any of the txn state on the opCtx (txnNumber, lsid, inMultiDocTransaction, etc) when checking a session in. In many cases this is okay, because the thread that yielded its session often did so just to wait for a network op. However, we sometimes to decide to yield for other reasons, e.g. during migrations, the thread yields its session in order to run local read ops. Because the read is local, the same opCtx will be used, so the lsid and txnNum will still be set on the opCtx - this previously could cause issues (SERVER-92335).

If we think it's actually correct that the txnNum, lsid, etc. state should remain set on the opCtx, then maybe we should consider preventing running operations on the same opCtx after yielding the session to avoid the confusing mix of states.