This specifically became of interest because one of the costs of WT shutdown in 4.2 and earlier was typically bounded by how much data had come into the system since the last checkpoint (or how far the stable timestamp moved since the last checkpoint). But with durable history, the cost is now bounded by how much data exists ahead of the stable timestamp (which is much easier to grow). This is because WT now calls rollback_to_stable inside of WT_CONNECTION::close.

Assuming that's the correct motivation/area of interest to target, one compromising solution is that MDB can explicitly call rollback_to_stable on shutdown while FTDC is still running. This would succeed if the following assumptions are true:

• WT_CONNECTION::close would not need to duplicate much if any of the work accomplished by MDB calling rollback_to_stable.
• WT produces meaningful metrics while rollback_to_stable is running.