In addition to the try { ... } catch (ClientException) introduced in issue #2795175 I think we should catch not only the ClientException but all GuzzleException.

Or is there a good reason to only check for GuzzleHttp\Exception\ClientException ?

I propose to change src/FetchManager.php so that we look for GuzzleHttp\Exception\GuzzleException instead of GuzzleHttp\Exception\ClientException.

I encountered the error:
Uncaught PHP Exception GuzzleHttp\Exception\ConnectException:
"cURL error 28: Operation timed out after 29943 milliseconds with 11168000 out of 38601468 bytes received
(see http://curl.haxx.se/libcurl/c/libcurl-errors.html)"
at [...]/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php line 185

Patch coming.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gngn created an issue. See original summary.

gngn’s picture

Here is the (very simple) patch.

Status: Needs review » Needs work
gngn’s picture

I do not understand what tests failed with #2.

Anybody?

Update:
The patch applied cleanly in my Drupal 8.5.6 installation (and worked).

gngn’s picture

Issue summary: View changes

Updated summary with error message.

neclimdul’s picture

Status: Needs work » Reviewed & tested by the community

Can't see anything wrong with this and the patch looks fine. Wager there was just some random failure way back when.

This will just throw away 50x and transfer failures and the like instead of tossing out an unhandled exception which seems to match what the code was trying to do already.

BarisW’s picture

Looks good, let's get this in.

  • BarisW committed 76b997c on 8.x-1.x authored by gngn
    Issue #2992856 by gngn, neclimdul, BarisW: Handle *all* guzzle...
BarisW’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.