Prior to 5.0, PreReceiveRepositoryHook and PostReceiveRepositoryHook modules were run with no active transaction. If a transaction was in-flight when they were called, that transaction was suspended. That ensured any methods hooks called that accessed the database would create read-only and read-write transactions as required, based on what they were doing.
Starting with 5.0, the new PreRepositoryHook and PostRepositoryHook instances are now run as part of any transaction that happens to be in-flight when the RepositoryHookService is called. Since PreReceiveRepositoryHook and PostReceiveRepositoryHook instances are now implemented using PreRepositoryHook and PostRepositoryHook adapters, respectively, this means they may also be called as part of an in-flight transaction.
In some cases this results in hooks being called as part of a read-only transaction, which results in unexpected and often difficult to debug behavior. For example, creating a new comment as part of a hook may run successfully, but then after the hook completes the comment wasn't actually added. This happens because the comment is created inside a read-only transaction and its creation is rolled back instead of being committed.