runOnException does not run on asynchronous exceptions

Abierto
  • ¿Algo no está bien?
#1,624 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
50/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
haskell
Área
database

Línea de trabajo

Comienza en runSqlPoolWithExtensibleHooks, especialmente en el bloque UE.mask y UE.catchAny marcado con HERE, y rastrea cómo se propagan las excepciones de timeout a través de la secuencia de hooks. Verifica el comportamiento de las excepciones asíncronas y define done como garantizar el comportamiento previsto de los hooks de excepciones sin romper la limpieza ni la semántica del rethrow.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Haskell
Estrellas
486
Forks
307
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de yesodweb/persistent

Todos los issues de yesodweb/persistent

Issues similares

Más issues de Haskell

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.