Open ForestEckhardt opened 1 year ago
If I could upvote this 100 times I would.
We looked into this and tried to implement the retry logic in cargo.Transport
and got to a working state.
But we wanted to add logging on retry (with backoff) so the users knows why nothing is happening. How would we inject a logger into the Transport
instance? We thought about adding a new constructor NewTransportWithRetry
while deprecating the old one.
Any opinions?
I'd prefer to find a way to add retry logic without requiring consumers to change the constructor. I think the way I would do this is make the logger optional (via a second constructor) and only interact with the logger during the retry loop if it is provided.
It's a bit gross, but I think it's worth it.
During test suites I often see failures that are coming from the buildpack having a network problem when downloading the dependencies. This issue is often resolved by rerunning the whole test suite again which takes time and leads to effort on false failures. It would be nice if the buildpack would try and do something like an exponential backoff attempt or even a simple retry when downloading artifacts.