isFulfilled: don't change resolution state, call in resolveSelect#78151
Merged
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
jsnajdr
added
the
[Type] Regression
|
Size Change: +28 B (0%) Total Size: 7.93 MB 📦 View Changed
ℹ️ View Unchanged
|
Member
|
If I'm tracking Gutenberg versions correctly, then regression can ship in WP 7.0; in that case, it makes sense to backport and avoid shipping incorrect behavior. @jsnajdr, what do you think about documenting this |
Member
Author
Good idea, it's something that:
|
johnhooks
approved these changes
May 11, 2026
Contributor
johnhooks
left a comment
johnhooks
left a comment
There was a problem hiding this comment.
I understand the need to revert.
Member
|
Sounds good to backport to 7.0 |
jsnajdr
force-pushed
the
fix/resolve-select-isfulfilled
branch
from
f12d857 to
d8914ba
Compare
Member
Author
Added I believe this is now ready to be approved, merged and backported 🚀 |
jsnajdr
added
the
Backport to WP 7.0 Beta/RC
Member
Author
@johnhooks The bug you originally reported, with the |
Mamaduka
approved these changes
May 12, 2026
Comment on lines
+130
to
+138
| resolvers: { | ||
| getPage: { | ||
| fulfill: ( id ) => async ( { dispatch } ) => { | ||
| const data = await fetchPage( id ); | ||
| dispatch( { type: 'RECEIVE_PAGE', id, data } ); | ||
| }, | ||
| isFulfilled: ( state, id ) => !! state.pages[ id ], | ||
| }, | ||
| }, |
Member
There was a problem hiding this comment.
Isn't technically a fulfill a resolver itself -getPage and then isFulfilled can be added as its object methods, or do folks have to use this pattern? A similar to how shouldInvalidate works.
Mostly, asking because the latter pattern is more common in core and probably what AI or copy-paste will be used for.
Member
Author
There was a problem hiding this comment.
That's right, it can be either a { fulfill, isFulfilled, shouldInvalidate } object, or a fullfill function with two optional fields. It will be always normalized internally to the object form.
I added a notice about it to the docs, and also documented shouldInvalidate, which is another optional resolver extension.
|
There was a conflict while trying to cherry-pick the commit to the wp/7.0 branch. Please resolve the conflict manually and create a PR to the wp/7.0 branch. PRs to wp/7.0 are similar to PRs to trunk, but you should base your PR on the wp/7.0 branch instead of trunk. |
|
Flaky tests detected in 7da7ca0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25723089051
|
Member
|
@jsnajdr, automated cherry-picking failed, you'll have to do it manually :( Do you think the flaky test report is related to this change? That test hasn't been flaky since last year. |
Member
Author
That flaky test fails very rarely, there are weeks, even months between failures. It fails when trying to embed the As the related code doesn't use But there's one suspicious thing: the wp.org URL has a trailing slash. If you try to enter this URL into the Embed block, it will be normalized to 
Only the one with slash is intercepted with So, I think there is a real bug in the Embed block, some race condition with URL normalization and sending the |
Member
Makes sense. I'll have a look, recently I've tried to improve those normalization effects and code for Embed block, I might have missed something. |
Member
Author
Looks like the described behavior is intended and explicitly written in the code. The Embed block first tries preview with the original slashed URL, and when it fails, it retries without the slash. It's our test that needs updating. Either:
|
Member
Author
The manual backport is in #78201. |
ellatrix
added
Backported to WP Core
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #78144 and partially reverts #70806. The
isFullfilledbehavior is now like:isFulfilledis called together withhasStartedResolution.start/finishResolutionare not called whenisFulfilledistrue.isFulfilledis called explicitly inresolveSelectto detect that the resolution has ended. Again, together withhasStartedResolution.isFulfilled. It's not a good idea to dispatchfailResolutionwhenisFulfilledfails. TheisFulfilledcallback is supposed to override thestart/finish/failResolutionlogic. They shouldn't interact with each other.There are some added/modified/removed tests:
stateis unmodified when selector withisFulfilled=trueis called. This is a separate commit, so you can try it out on the old version. It should fail and report two calls to thesubscribecallback. One onstartResolution, second onfinishResolution. After this PR, the number of calls should be zero.isFulfilled. It's now called insideresolveSelecton each Redux state update, the number of calls is no longer so deterministic.hasFailedResolutionafterisFulfilledthrows.Idea for future evolution: the
isFulfilledcall should probably be integrated directly into thehasStartedResolutionandhasFinishedResolutionselectors, and make them returntrue. That way, user-space code would get the right results. Right now that doesn't happen.@Mamaduka @ellatrix is it a good idea to backport this to 7.0?