Currently, the ScopedLocalCatalogWriteFence refreshes the internal state of the ScopedCollectionAcquisition in a rollback handler. This has two problems:

1. We have an implicit order dependency on how rollback handlers execute. The fence is expecting the local catalog state to have already been rolled back when its own rollback handler executes. The onCommit/onRollback system was not designed to handle dependencies between handlers.

2. When the ScopedCollectionAcquisition is located outside a write conflict retry loop the rollback handling need to actually advance the local catalog state. Depending on what it observes an error condition may occur that is unable to be handled with our regular exception handling due to exceptions thrown from rollback handlers not being allowed. There is currently a workaround that defers the error handling by marking the acquisition as invalid.

Ideally, acquisitions should not be scoped outside write conflict retry loops. But due to legacy code, this is not feasible to achieve in the short term.

Potential solutions of the above include:

• Custom writeConflictRetry loop overload that takes an acquisition and internally performs the regular yield logic in the case of retry. This ensures we have a common way to deal with refreshes and handling of incompatible state.
• ScopedLocalCatalogWriteFence restores the original state from the time of its construction, this should be fine in the regular case where the acquisition is scoped within the write conflict retry loop.