Compact generates an error message when it can't lock a page because checkpoint is working in the same tree:

WT_SESSION.compact  Data handle compaction failed with EBUSY but the cache is not stuck. Will give it another go.

This is an accurate description of what is happening internally – compact tried to acquire the btree's flush_lock and because checkpoint already held the lock, compact got an EBUSY error. But this message may be confusing to users. Saying compact "failed" suggests that something went wrong when this is, in fact, expected behavior.

We should reword this to be more useful for a user running compact.