Commit handlers do not run atomically for lock-free reads which is a common source of bugs. When commit handlers were designed no readers could observe a partial state as locks were held.

An example of an issue is that adding idents to the drop pending reaper and dropping collections/indexes are currently not atomic operations as they execute in separate onCommit handlers and perform separate writes to the CollectionCatalog.

This leads to a dependency on the order that these onCommit handlers must execute: first adding the drop pending idents to the reaper and then making the drops visible for readers by publishing uncommitted catalog changes.

These kinds of dependencies are fragile and are currently implemented with hacky solutions with special ways to register the onCommit handlers so they execute in the required order. We should look into ways to clean this up, some ideas:

1. Make these two writes atomic by performing them under the same CollectionCatalog write. We would need to figure out how to structure the code, should the CollectionCatalog be treated as a write-through cache or should we add a way to register special callbacks that execute as part of catalog visibility.
2. Snoop the commitTime as it should have been registered on the RecoveryUnit after