When streaming Docker events, you typically don't want to timeout at all — you want to keep reading forever until your own control logic kicks in to stop streaming. Read timeouts can be disabled in Excon by passing read_timeout: 0|nil, but docker-api only supports passing 0: the null-check in compile_request_params strips out read_timeout: nil, effectively mapping it to the default timeout value (60).
The README currently suggests setting Docker.options[:read_timeout] to a very high value, but this is bad for two reasons:
- It's global, and a very high timeout is bad in almost all other circumstances.
- You probably actually want no timeout when streaming events, not just a high one.
I suggest updating the Docker::Event.stream documentation with an example of disabling read timeouts completely.
I would also consider making read_timeout: 0 the default for that specific method, since that is the least surprising behavior and the one most likely wanted by users. This is a much more significant change, however, and would necessitate at least a minor version update.
When streaming Docker events, you typically don't want to timeout at all — you want to keep reading forever until your own control logic kicks in to stop streaming. Read timeouts can be disabled in Excon by passing
read_timeout: 0|nil, but docker-api only supports passing0: the null-check in compile_request_params strips outread_timeout: nil, effectively mapping it to the default timeout value (60).The README currently suggests setting
Docker.options[:read_timeout]to a very high value, but this is bad for two reasons:I suggest updating the Docker::Event.stream documentation with an example of disabling read timeouts completely.
I would also consider making
read_timeout: 0the default for that specific method, since that is the least surprising behavior and the one most likely wanted by users. This is a much more significant change, however, and would necessitate at least a minor version update.