-
Notifications
You must be signed in to change notification settings - Fork 24
provider: request_timeout is ignored #42
Comments
@rjeczalik I've got a feeling that this was accidently overridden for the case when we want to watch the deployment. Rather, we should probably have a different timeout when watching the deploy. |
It looks like go-marathon is pulling in |
Looks like eventsource uses some XHR for polling on events. Yes, http.Client cancels http request after Timeout is reached (if Timeout != 0). In case of streaming API Timeout should not be used if the library does not automatically reconnect (in case of temporary network errors). |
We likely should create a different http client for reading off the event stream then. The provider's client could be used for single get/post/put/delete events. |
Currently
request_timeout
(configured here [0]) is overwritten withdeployment_timeout
[1].Two questions:
min(request_timeout, deployment_timeout)
?request_timeout
affect only plain http request/response and not span over deployment operation? if the former, shouldn't the (*http.Client).Timeout be unset (0) and we implement the timeout by polling the deployment status? Currently it's not possible to distinct temporary networking errors from marathon api timeouts.[0] https://github.com/Banno/terraform-provider-marathon/blob/1ccf8237686780c3e77fefe173293de31199b7ea/marathon/provider.go#L66-L68
[1] https://github.com/Banno/terraform-provider-marathon/blob/1ccf8237686780c3e77fefe173293de31199b7ea/marathon/provider.go#L76-L78
The text was updated successfully, but these errors were encountered: