🐛 Optimizing Sentry Integration: Making Initialization Optional and Enhancing Exception Reporting

[kneerose]

Context

I am working on making Sentry initialization optional to control its usage across different deployment environments. This will allow us to enable Sentry selectively based on the deployment environment. On the frontend, I have updated some options for this purpose. PR #2449. Your feedback is welcome and appreciated.

On the backend, Sentry is currently initialized every time an exception is triggered because it is integrated with the exception handler. A better approach would be to initialize the Sentry service once when the application starts and then use it only to send reports when exceptions occur, instead of reinitializing and sending reports on each exception.

Current Sentry Integration on Backend

exceptionHandler :: VVAConfig -> Maybe Request -> SomeException -> IO ()
exceptionHandler vvaConfig mRequest exception = do
  print mRequest
  print exception
  let isNotTimeoutThread x = case fromException x of
        Just TimeoutThread -> False
        _                  -> True
      isNotConnectionClosedByPeer x = case fromException x of
        Just ConnectionClosedByPeer -> False
        _                           -> True
  guard . isNotTimeoutThread $ exception
  guard . isNotConnectionClosedByPeer $ exception
  let env = sentryEnv vvaConfig
  sentryService <-
    initRaven
      (sentryDSN vvaConfig)
      id
      sendRecord
      silentFallback
  register
    sentryService
    "vva.be"
    Error
    (formatMessage mRequest exception)
    (recordUpdate env mRequest exception)
    ```