Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't discard all promises results when one of them rejects #25302

Merged
merged 2 commits into from
Sep 21, 2020

Conversation

alshakero
Copy link
Contributor

@alshakero alshakero commented Sep 14, 2020

Description

Hi there!

Some blocks, such as the Link block, have a search feature for URLs. This feature searches against 3 endpoints with different query params. These searches run concurrently using Promise.all. Good design but with one flaw, if any of the searches fail, all the results are discarded, due to the nature of Promise.all.

This PR proposes using Promise.allSettled instead. It resolves even if one or two promises fail out of 3. I think it makes more sense since the other two promises can provide valid results just fine.

Edit: I removed Promise.allSetted due to the support question.

This PR proposes catching each failing request and returning an empty array in the catch handler, denoting an empty result. This gives the chance for the other successful promises to prevail.

The issue has surfaced when one of the searches started failing as shown here.

How has this been tested?

I tested using a local Gutenberg instance.

Side note

This fix is an improvement and should be probably merged anyways. But there is also an underlying issue, it's explained in this comment.

Types of changes

bug-fix

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

Copy link
Contributor

@ntsekouras ntsekouras left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey thanks for working on this!

I haven't checked thoroughly about Promise. allSettled current support but the Implementation Progress section doesn't make me 100% sure. (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled)

} );
// use allSettled to preserve any successful promise(s) results when one of the promises fail
return Promise.allSettled( queries )
.then( ( results ) =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you use only one then?

} );
// use allSettled to preserve any successful promise(s) results when one of the promises fail
return Promise.allSettled( queries )
.then( ( results ) =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some as above.

@alshakero alshakero changed the title Don't discard promises results when one of them fails Don't discard all promises results when one of them fails Sep 15, 2020
@alshakero alshakero changed the title Don't discard all promises results when one of them fails Don't discard all promises results when one of them rejects Sep 15, 2020
@alshakero
Copy link
Contributor Author

Thanks for the review @ntsekouras! I found a more supported way to fix this.

@@ -66,7 +66,7 @@ const fetchLinkSuggestions = (
type: 'post',
subtype,
} ),
} )
} ).catch( () => [] ) // fail by returning no results
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the error important for us to know about?

In other words, will discarding the error entirely be problematic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. But the failure wasn't handled before this change anyways, so there is no regression.

Copy link
Member

@noahtallen noahtallen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that these errors were not handled before, this seems like a safer approach. Ideally, I feel like we'd handle these "properly," whatever that means!

@simison simison added this to the Gutenberg 9.1 milestone Sep 21, 2020
@sirreal sirreal merged commit 90f17a3 into WordPress:master Sep 21, 2020
@alshakero alshakero deleted the patch-2 branch September 21, 2020 19:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants