Allow client function to wait then retry after an error via purrr?

[PietrH]

On the client side, API calling code could be wrapped in:

purrr::insistently(f, rate = purrr::rate_backoff(), quiet = TRUE)

Docs:

• insistently
• rate_backoff (rate helpers)

Currently postman tests mostly fail because the 3s deadline is not met, however, on occasion other error codes are returned. These need to be captured client side and translated in clear error messages for the user, but before it comes this far, it would be beneficial if the function would try again (perhaps with a notification that this is being attempted).

The most pragmatic solution to me is on the client side, via purrr, as above. However, a server side solution could be possible where the server waits for confirmation from the client that the response is satisfactory. But I think this is adding unnecessary additional complexity and server load, as two subsequent queries to ETN should deliver the same result except in extreme edge cases where data is being edited between the two calls.

See also: two general's problem

In any case, this is an additional argument to minimize the time it takes to return a query as well as package size.

[PietrH]

Switching to httr2 and using req_retry() is a better idea

[PietrH]

Maybe a good idea when I migrate from httr to httr2

[PietrH]

get_val() currently uses {httr}::RETRY:

https://github.com/inbo/etn/blob/9bb4250b9a1c387edc837de576e0f87207ee8046/R/utils.R#L161-L171

and so does forward_to_api():

https://github.com/inbo/etn/blob/9bb4250b9a1c387edc837de576e0f87207ee8046/R/utils.R#L297-L304

Closing for now, but switching to httr2 is a good idea for the long run