Clean way to retry http requests?

[Daniel Bachler]

Hi,

I'm thinking about how to handle retry for http requests and was wondering if anyone had already tackled that problem. A search here on the ML turned up empty, does anyone have any pointers?

For a bit more context: I have an app that creates a lot http requests during it's lifetime and during the initial development I just logged the errors, but now I would like a sane way to handle those cases. Since things like a bad wifi connection can lead to any random subset of requests failing, I would like to keep track of which requests are in flight, remove then when they are successful and otherwise retry them (maybe repeatedly after increasing delays). Since dependent tasks are only emmited inside update when the previous task has succeeded I think that I do not need any kind of dependency information for the tasks in flight.

If no prior art exists I am thinking of writing a small library that handles this. Are there other effects than http requests where it would make sense to retry them? Should this library operate on tasks? Would there be a problem in storing the configured task and just emmiting that again as an effect to retry?

I'd appreciate any comments!

[Peter Damoc]

In theory, this should be modeled.

So, if you have a task that you expect to fail and you want to retry, just add an Action for the case where the task fails and update the model with the count of the retry. 

Using the count, you can also implement some sort of delay for the task. 

If you want the pending tasks to be removable, again you need to be explicit and model it with some kind of pending list and timed retry. 

If you can pattern the use-case, by all means, create a library. 

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Daniel Bachler]

Thanks for your input, Peter.

I do feel like this behaviour makes sense for most api end points in my app and so I will try to model a library around that use case. It seems to me that retries with growing delays are a pretty good default handling of many kinds of http errors (depending on the specific kind of error/status code returned of course - there is little point in retrying a http request if decoding the json reply failed).

[Luke Westby]

Here's a very naive implementation of retrying a request from builtwithelm that I did just for fun

https://github.com/elm-community/builtwithelm/blob/master/src/Request.elm