[AaronBarnes07]

Requests now have a connect and a read timeout.

The client sent requests with no timeout, so a request to a server that accepts the connection and never answers did not return. A nightly smoke test hung for 15 hours this way: its login request waited on a TLS handshake that never finished.

• DataMasqueInstanceConfig and DataMasqueIfmInstanceConfig have connect_timeout_seconds (default 10) and read_timeout_seconds (default 300).
• Each client stores the pair and passes it as timeout on every request, including the IFM login and token refresh.
• A request that times out raises DataMasqueTransportError.
• Listed under 1.6.0 (unreleased) in HISTORY.rst, with the project field changes.

Tested against a local server that accepts the connection and never completes the handshake: 1.2.5 was still waiting when killed after 15 seconds, and this branch raised DataMasqueTransportError after its 2-second timeout.

[cph-datamasque]

300s sounds like quite a long timeout, but I kinda get it - we have certain slow endpoints like the RG CSV stuff.

Do we need to make a session adapter thing, instead of just storing off the (connect_timeout, read_timeout) tuple on the client class and passing it as a timeout parameter to the request call?

[AaronBarnes07]

Switched it to storing the (connect, read) tuple on the client and passing timeout on each request, kept 300s for the slow ones like the RG CSV stuff