When logical session refresh decides which transaction sessions to remove history for it uses two separate lookups into the logical session collection (one here and another here), which may return different results for the same session, leading the internal transaction machinery that is meant to prevent reaping transaction sessions for child sessions if another session in its "family" is still in use.

In particular the sequence is:

1. Logical session reaping looks for transaction sessions that have expired in the process's in-memory SessionCatalog
2. For those that expired, lookup from config.system.sessions if that logical session has globally expired
3. For those that globally expired, remove it from the in-memory SessionCatalog only if no "sibling" child sessions are in use
4. Remember which "expired" transaction sessions actually couldn't be reaped because they failed the check in 3)
5. For each transaction entry in config.transactions that hasn't been written to in over 30 minutes, remove it if its session has globally expired, by checking in config.system.sessions, and if it isn't in a session family skipped over from step 3) above

If the read in 2) does not find a logical session has expired, we won't remember it as having been skipped over in step 3), so if the read in step 5) does find the session has expired, it will go ahead with removing the transaction session entry.