We have seen build failures with a stuck cache when running the FSM suite and compact tasks are in flight.

Diving into the issue, it appears that the compact operation runs over multiple WT_SESSION objects. A first session, with an "empty" transaction is opened when the command is in the early stages, then subsequent sessions are taken from the session cache to run compact on the record store and each index.

This can cause problems in testing due to there being a single transaction running for the length of all the compact operations.

There may also be scope here for a more full review of places in the WiredTiger KV Engine that we can go through and find locations that also exhibit this behaviour of opening sessions with transactions that are never used or taking sessions directly from the session cache.