Core Data: Fix selectors returning stale results for different 'per_page' queries#76422
Core Data: Fix selectors returning stale results for different 'per_page' queries#76422
Conversation
…age' queries Queries with different `per_page` values share the same `stableKey`, causing selectors to return cached items from a prior query instead of null while the new query resolves. Add a check in `getQueriedItemsUncached` that returns `null` when stored `itemIds` can't satisfy the requested pagination range and `totalItems` confirms more items exist.
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @kozack-webspark. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. 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. |
|
Size Change: +32 B (0%) Total Size: 8.75 MB
ℹ️ View Unchanged
|
| itemIds = state.queries[ context ][ stableKey ].itemIds; | ||
| } | ||
|
|
||
| const itemIds = state.queries?.[ context ]?.[ stableKey ]?.itemIds; |
There was a problem hiding this comment.
Unrelated. Just a minor cleanup.
|
Flaky tests detected in 8338e14. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22991562546
|
ramonjd
left a comment
There was a problem hiding this comment.
What magic is this?! I can confirm it fixes #56355
I also created 100 pages and couldn't find any regressions using the data views-driven page list in the site editor.
I'll yield the floor to @andrewserong, who reported the issue, and/or @jsnajdr to double check but it LGTM. Thank you!!
andrewserong
left a comment
There was a problem hiding this comment.
I'll yield the floor to @andrewserong, who reported the issue
Wow, that was so long ago, I can barely remember! 😄
I like the fix thanks for working on it @Mamaduka 👍
✅ If the per_page is smaller than the items we've already got, then the cached value is returned
✅ If the per_page is larger than the items we've already got, then we get null in the first call, and in subsequent calls we get the cached results
This feels like how I'd expect it to work, and nice that you came up with a way to fix it without changing the stableKey (returning null effectively means that the value won't be treated as cached, so the change here correctly increases the cache misses) 🎉
LGTM! 🚀
|
Thanks for testing and feedback, everyone 🙇 |
|
Looks like we missed that |
What?
Closes #56355.
Queries with different
per_pagevalues share the samestableKey, causing selectors to return cached items from a prior query instead ofnullwhile the new query resolves. Add a check ingetQueriedItemsUncachedthat returnsnullwhen storeditemIdscan't satisfy the requested pagination range andtotalItemsconfirms more items exist.Note: The new guardrail might fail when
totalItemsand the query return stale data, but that should be very rare.How
Tries to fix the bug without changing the query
cacheKey.Testing Instructions
Testing Instructions for Keyboard
Same.