itsfadnis
Feat/fetch retry and error handling
A slightly naive implementation of retry logic to mitigate transient errors communicating with the intake. Can be improved down the line by filtering HTTP response codes such as 401 that should not cause a retry as they're not transient.
Found some time today to improve the retry logic slightly. It now only retries HTTP 500 and greater errors. Anything in the 400 range is considered a 'persistent' error and isn't retried - the POST bails immediately. There are a couple of test cases to cover each scenario.
Apologies for the delay in getting back - holiday season!
I like the idea of a callback, it definitely adds more flexibility, I'm playing with some ideas around it at the moment. The key for me, I think, is to allow the caller to have enough information to handle retries, back offs etc. easily. My thinking is that an enriched version of the original log request that includes the number of failures would probably no the job.
I think supplying an 'out-of-the-box' retry implementation that can be used for the hook handler is also something we should consider, so users have a really simple, zero(ish) config to just get something reliable working.
Will try and get something up this weekend!