req
req copied to clipboard
wojtekmach
`retry`: Make retry interface a bit more flexible
The Req.Steps.retry/1 docs state that the retry-after header is only read in case of a 429 status, while the combo of the retry and retry_delay function options does not permit deciding on whether to retry say, based on the status, and then returning the delay retrieved from the retry-after.
Can this be made a little bit more flexible? I for instance need the functionality reserved for the 429 status in :retry_delay but for the 503.
Thanks
@wojtekmach
In absence of a better place to ask you this, did you have issue reports of the following:
[error] Task #PID<0.2031.0> started from #PID<0.2030.0> terminating
** (Mint.TransportError) non-existing domain
(req 0.3.11) lib/req.ex:958: Req.request!/2
This happens to me from time to time and I don't really know what to do with it. The only thing that helpers is shutting the LV instances with all of its processes.
Maybe related, I manage the timeouts myself by killing the async task (my async task that among other things such as caching, invokes Req) when the server is taking too long to respond. Can this be the cause of such behavior?
Also, it'd be good to know more on on the circumstances of this "non existing domain" error, for I change exactly nothing when I shut the LV instance down and it beings working again properly.
EDIT: This comment has nothing to do with this closed issue.
If this error happens randomly ie the domain is actually good, search for :nxdomain on Mint and Finch issue tracker and see if something pops up.
The problem is when this happens, it does not stop (all subsequent requests raise until the LV instances are shut down).
If this error happens randomly ie the domain is actually good, search for :nxdomain on Mint and Finch issue tracker and see if something pops up.
Just to update you on this issue. I have replaced ALL calls of the bang functions (that raise the Mint exceptions) with the calls to functions that return errors and the thing now miraculously heals itself (after a series of logged Mint transportation errors that would otherwise raise) under one condition: one must not kill the process invoking Mint/Finch through Req, even when started as an async Task that is no longer needed (given the fact that it went into a caller managed timeout). Killing such task would mess up something with Mint/Finch internals.
The take away: IMO you should recommend using non-bang functions and letting async tasks complete on their own (the process using them must treat that explicitly if a GenServer, i.e. a LiveView instance or a scheduler or a cache process).
I’ll reopen this as a reminder to learn more because it isn’t immediately obvious to me.
I’ll reopen this as a reminder to learn more because it isn’t immediately obvious to me.
Just letting you know that this Mint issue is still alive and well. The only remedy so far has been the one with avoiding any kind of killing the processes that use it (i.e. that use your lib too) while they're still waiting for the response. Now, this becomes a problem in a multi-liveview app that switches from one sub-app to another each being a liveview instance of its own, for each such liveview is a process and when killed automatically it will result in all linked processes to be killed as well and this issue will reoccur if at the time of killing it it was waiting for a response - meaning that ideally ALL requests should be fired exclusively from non-linked async tasks only and let die on their own. Naturally, if any of them has a bug it will crash and consequently risk a reoccurrence of the issue again.