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.
Comment | File | Size | Author |
---|---|---|---|
#2 | stage_file_proxy--handle-all-guzzle-exceptions-2992856-2.patch | 799 bytes | gngn |
Comments
Comment #2
gngn CreditAttribution: gngn at Computer Manufaktur GmbH commentedHere is the (very simple) patch.
Comment #4
gngn CreditAttribution: gngn at Computer Manufaktur GmbH commentedI do not understand what tests failed with #2.
Anybody?
Update:
The patch applied cleanly in my Drupal 8.5.6 installation (and worked).
Comment #5
gngn CreditAttribution: gngn at Computer Manufaktur GmbH commentedUpdated summary with error message.
Comment #6
neclimdulCan'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.
Comment #7
BarisW CreditAttribution: BarisW at LimoenGroen commentedLooks good, let's get this in.
Comment #9
BarisW CreditAttribution: BarisW at LimoenGroen commented