guzzle: Connection or File Descriptor leak when HTTP Exception occurs in async batch

Guzzle version(s) affected: 6.3.0 and possibly older versions

Description
When using the async feature to make a batch of requests in parallel, if one of those requests responds back with an exception type response (example, one of them is a 404 and the rest are normal 200) there will be an open file descriptor somewhere in the stack – e.g. fclose is not being closed properly on something – with no way of cleaning up this open handle except by quitting the process (not valid for long running PHP scripts).

How to reproduce
Reproduce is simple using a fairly simple script, occurs on Linux based system but also macOS with PHP 7.1.

1. Have PHP 7.1 installed with cURL available, on a linux or macOS system
2. Download gist to an empty dir and name it gist.php
3. Run composer require guzzlehttp/guzzle to get latest guzzle installed into vendor/
4. Run php gist.php

Expected: Because the inner code operates in a function with only local variables, we expect that as execution exits the function, all objects that were created would have their __destruct() called, freeing up any open handles that were generated.

Actual: As the script runs and the URLs are hit in parallel, the number of open file descriptors (labeled as OPEN FDs in the debug output) increases for every iteration (the main loop runs 4 times total). For bigger running batch scripts you could imagine that eventually the “open file limit” will be hit due to HTTP exceptions and bad URLs occurring.

Inverse case To observe what would happen in a perfect world where file descriptors are NOT kept open, we can make sure all URLs respond with a 200:

1. Comment out using // on line 51, save and re-run the test script
2. Notice that since all URLs are 200 and no exceptions occur, the file descriptors (OPEN FDs) never increase indefinitely, they’ll stay as some static number.

Possible Solution
Likely something to do with the way CurlHandler, CurlMultiHandler, or CurlFactory works. However it could be an internal PHP or CURL bug. Could also be the Guzzle Promises implementation.

Additional context