1. 12 May, 2025 1 commit
    • Alfredo Di Napoli's avatar
      Port DB operations to transactional API · 53512f89
      Alfredo Di Napoli authored
      This gigantic commit ports the existing DB operations in GGTX to use the
      transactional API, meaning that we can now compose DB operations and
      they will all run in the same Postgres transaction using the same
      connection, which will eliminate those class of bugs where concurrent DB
      access might result in an inconsistent state.
      
      On top of that, we simplify some parts of the API, for which a summary
      is given below:
      
      1. The `NodeStoryEnv` management has been greatly simplified; in the new
         API we don't need an external connection pool to be passed and we
         don't have to pass IO actions, we can just pass DB operations,
         therefore we can greatly simplify the API to just pass mostly pure
         values;
      
      2. Due to the fact that our `DBTx` monad can't do arbitrary IO (which is
         a good thing) we cannot fire Central Exchange notifications
         immediately. Rather that happens now is that we collect the
         `CEMessage` to be sent and we fire them in the relevant concrete
         monad after we finished with the DB transaction. This means that in
         principle there would be a small delay between the DB operation
         taking place and the notification firing but in practice the latency
         should be negligible and bear in mind this is typically what we want:
         if we have a long DB Tx that triggers an error in the middle we don't
         want to be sending out CE messages prematurely if the overall
         operation didn't succeed!
      
      3. There are still a few places in the codebase where we couldn't make
         things fully compositional with regards to the DBTx API, because we
         had Servant handlers which had DB operations mixed with other IO
         effectful computations (or other things like the notification from
         the `MonadJobStatus`). For now we are splitting these functions by
         manually running the partial DB operations, and while this is not
         ideal it can be fixed in subsequent merge requests.
      
      4. The `WorkerEnv` doesn't use `IOException` as its `MonadError`
         anymore, as for consistency we can just use `BackendInternalError` by
         adding a `InternalWorkerError` data constructor accepting the
         `IOException` triggered by the Worker monad.
      
      More testing is needed, with particular attention to performance
      (regression) but this should hopefully offer a decent baseline.
      53512f89
  2. 14 Nov, 2024 1 commit
  3. 11 Nov, 2024 1 commit
    • Alfredo Di Napoli's avatar
      Correct FrontendError for policy check failures · cb49e82a
      Alfredo Di Napoli authored
      It also:
      
      * Amends tests for policy checks status code changes
      * Fix a bug in isNodeReadOnly
      * Adds a function to return all the nodes ids for the published
        nodes. Next we need to modify `findShared` & co to make sure that
        published notes will show somewhere in the users' tree.
      cb49e82a
  4. 25 Mar, 2024 1 commit
  5. 04 Dec, 2023 1 commit
  6. 12 Oct, 2023 1 commit
  7. 11 Oct, 2023 1 commit
  8. 23 Dec, 2020 1 commit
  9. 13 Oct, 2020 1 commit
  10. 15 Jul, 2020 1 commit
  11. 03 Jun, 2020 1 commit
  12. 02 Jun, 2020 1 commit
  13. 01 May, 2020 1 commit
  14. 29 Apr, 2020 1 commit
  15. 28 Apr, 2020 1 commit
  16. 13 Apr, 2020 3 commits
  17. 12 Apr, 2020 1 commit
  18. 11 Apr, 2020 1 commit
  19. 26 Feb, 2020 1 commit
  20. 24 Feb, 2020 1 commit