Files: 
CommentFileSizeAuthor
#11 update-fetch-guzzle-1862538-11.patch1.21 KBBerdir
PASSED: [[SimpleTest]]: [MySQL] 53,859 pass(es).
[ View ]
#9 update-fetch-guzzle-1862538-9.patch1.21 KBBerdir
PASSED: [[SimpleTest]]: [MySQL] 53,903 pass(es).
[ View ]
#3 update-guzzle-1862538-3.patch1.41 KBBerdir
PASSED: [[SimpleTest]]: [MySQL] 50,760 pass(es).
[ View ]
#1 update-guzzle-1862538-1.patch2.36 KBBerdir
FAILED: [[SimpleTest]]: [MySQL] 49,252 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new2.36 KB
FAILED: [[SimpleTest]]: [MySQL] 49,252 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

Another easy conversion, haven't run the tests yet.

Status:Needs review» Needs work

The last submitted patch, update-guzzle-1862538-1.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new1.41 KB
PASSED: [[SimpleTest]]: [MySQL] 50,760 pass(es).
[ View ]

This should pass the tests and is more like the original code.

Looks good to me.

#3: update-guzzle-1862538-3.patch queued for re-testing.

Status:Needs review» Reviewed & tested by the community

I've got nothing to add. It's RTBC to me.

Status:Reviewed & tested by the community» Needs review

Needs to be re-rolled to use the exception handling pattern from the standardize issue. Which should probably wait until that is commited.

Otherwise, this will result in an uncatched exception bubbling up all the way if e.g. the network or d.o is down.

here is the standardize issue @Berdir suggests going in first: #1875792: Standardize Guzzle exception handling

StatusFileSize
new1.21 KB
PASSED: [[SimpleTest]]: [MySQL] 53,903 pass(es).
[ View ]

Re-roll. Looks better now :)

Status:Needs review» Needs work

just one thing

+++ b/core/modules/update/update.fetch.incundefined
@@ -149,12 +151,13 @@ function _update_process_fetch_task($project) {
+    } catch (RequestException $exception) {

should be in a newline after closing }

Status:Needs work» Needs review
StatusFileSize
new1.21 KB
PASSED: [[SimpleTest]]: [MySQL] 53,859 pass(es).
[ View ]

There you go. Was too lazy for an interdiff ;)

Status:Needs review» Reviewed & tested by the community

ready to fly, thanks:)

And what about BadResponseException?

That's a subclass of RequestException. We only need to differentiate if we want to log different errors otherwise re-act differently on them. I think the default getMessage() of either exception is fine for this.

Ahh, right.

Status:Reviewed & tested by the community» Fixed

Committed 28f278b and pushed to 8.x. Thanks!

Status:Fixed» Closed (fixed)

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