Don't use http.DefaultTransport in the CLI #77
Comments
|
I'm planning on adding several nesting transports/clients that we've added to the python client (for good reasons). I can add a default timeout at the same time as that refactor. |
|
FWIW, |
@adrcunha continuing here I think that issue doesn't get much attention because for most people (at least for me), using For the integration tests, a network flake means we have to teardown/recreate the entire universe and rebuild everything :( If this really is an issue for y'all, we happily accept pull requests and bribes 😉 The would be to replace this with something simple that will retry low-level network errors once or twice: |
We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Also, stop using the default transport. It doesn't set timeouts for headers, so it can hang forever and cause us to get stuck. Fixes google#77
We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Fixes google#77
We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Fixes google#77
We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Fixes google#77
We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Fixes google#77
We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Fixes google#77
We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Fixes google#77
We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Fixes google#77
* Add retries for temporary network issues We pretty commonly see this issue when communicating with a registry: ``` Get https://gcr.io/v2/: net/http: TLS handshake timeout ``` This causes a huge amount of pain if it's a failure within e.g. a large CI job, since the entire thing would fail. Fixes #77 * Rename options
It has no timeouts.
See: golang/go#24138 and https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/
The text was updated successfully, but these errors were encountered: