Robustness for hooks taking too much time

[tobast]

Hello,

Today, I experienced an issue with a radicale hook that was taking too much time: I had a git push in my radicale hook, and some network issues made the command hang forever.

While the issue was entirely my fault, it was tricky to debug, and I believe that Radicale could be made a bit more robust, or at least produce clear log messages, in this case.

What happened

While the hook was taking forever to complete, the gunicorn worker timed out, and nginx responded to the request with 502. Thunderbird handled this gracefully, with network connectivity issues, and on the next sync, the event modified by the request that failed (but which was actually updated server-side by the request nevertheless) would be correctly synced. Davx5 retried continuously to update the event that it assumed to be incorrectly synced, producing errors at every retry.

What is expected

Actually, this behaviour is pretty much expected — it is the hook's fault. However, a timeout with a reasonable delay for the hook command might make this more manageable? This way at least, radicale could produce an error logline that would directly point out the culprit.

[pbiering]

sounds to me like a at least a dedicated thread or even a process should take care about hooks to run them in asynchronous way like a persistent spooling which even survives a restart of "radicale"

[tobast]

Persistent spooling looks like a bit overkill to me, but starting the hook in a thread/process/anything asynchronous looks very reasonable to me. Unless there is indeed a usecase for blocking hooks, eg. postprocessing the data just submitted, so that a hook failure should return a failure to the client? (This would look a bit fragile to me, though)