We intend to instrument our use of DB connections by incrementing and decrementing a gauge through hooks,

let
 hooks' = hooks
 { runBefore = \conn mi -> do
 Stats.incGauge gauge
 runBefore hooks conn mi
 , runAfter = \conn mi -> do
 Stats.decGauge gauge
 runAfter hooks conn mi
 , runOnException = \conn mi e -> do
 Stats.decGauge gauge
 runOnException hooks conn mi e
 }

We find that the gauge tends to just keep incrementing over time, as if there are cases where we increment but never decrement.

Our best theory is that when a web request times out (using timeout), the asynchronous exception does not result in runOnException firing.

That means when our DB is overloaded, our connection pools start to get exhausted, and we begin timing out requests, our active-connections metric goes sideways -- exactly when we'd want to use it.

The code seems to support that:

runSqlPoolWithExtensibleHooks r pconn i SqlPoolHooks{..} =
 withRunInIO $ \runInIO ->
 withResource pconn $ \conn ->
 UE.mask $ \restore -> do
 conn' <- restore $ runInIO $ alterBackend conn
 _ <- restore $ runInIO $ runBefore conn' i
 a <-
 restore (runInIO (runReaderT r conn'))
 `UE.catchAny` \e -> do -- <-- HERE
 _ <- restore $ runInIO $ runOnException conn' i e
 UE.throwIO e
 _ <- restore $ runInIO $ runAfter conn' i
 pure a

The use of UniftIO.Exception.catchAny means only synchronous exceptions would be caught. Others, such as Timeout, would never result in runOnException firing.

Can this be changed to also catch and rethrow asynchronous exceptions? I know handling asynchronous exceptions can be Bad, but I wonder if given the likely use case of a web server, where the main process is almost never going to die (the usual way a missed cleanup finally gets dealt with), perhaps guaranteeing runOnException runs is more important.