Feature summary:

If feasible, consider extending MultiHttpClient (i.e., in runMultiCurl) to surface session-level error details by way of curl_error, rather than the generic translation of the returned error code using curl_strerror as it does now.

Aside: I realize that if T202352 is prioritized, we may very well get this for free.

Use case(s):

In T422455, an issue affecting DNS resolution latency led to a large increase in EtcdConfig fetch timeouts.

Unfortunately, the generic (curl error: 28) Timeout was reached errors reported by MultiHttpClient did not reveal the specific phase of request lifecycle that was in progress at timeout (in this case, DNS resolution). We only happened to make the connection that the underlying issue may be DNS-related due to a far lower rate of errors surfaced by a Guzzle-based client (Shellbox) [0], which indeed uses curl_error when reporting errors (T346971#11791136).

Benefits:

Faster diagnosis of issues impacting MultiHttpClient-issued requests.

[0] e.g. ConnectException: cURL error 28: Resolving timed out after 5000 milliseconds