[WIP] Real-time Collaboration: Cache awareness state to reduce postmeta queries#11067
[WIP] Real-time Collaboration: Cache awareness state to reduce postmeta queries#11067mindctrl wants to merge 6 commits intoWordPress:trunkfrom
Conversation
…meta in WP_Sync_Post_Meta_Storage
…h_suspended_posts_last_changed_update() Co-authored-by: gemini-cli <176961590+gemini-code-assist[bot]@users.noreply.github.com>
…tion in sync storage Fixes a race condition in `get_updates_after_cursor` where updates inserted during the fetch window could be skipped by the next poll. The method now snapshots `max_meta_id` before fetching to ensure a consistent cursor. Optimizes `remove_updates_before_cursor` to use a single atomic `DELETE` query instead of the previous read-delete-write approach. Cleanup now uses direct SQL deletion to bypass `clean_post_cache`. This prevents sync operations from updating the global `posts_last_changed` salt, avoiding site-wide cache invalidation storms during high-frequency editing sessions. Includes a regression test using a WPDB proxy to deterministically reproduce the race condition.
|
Hi @mindctrl! 👋 Thank you for your contribution to WordPress! 💖 It looks like this is your first pull request to No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description. Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making. More information about how GitHub pull requests can be used to contribute to WordPress can be found in the Core Handbook. Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook. If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook. The Developer Hub also documents the various coding standards that are followed:
Thank you, |
|
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 Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
|
@mindctrl The transients API is designed in such a way that persistence isn't guaranteed. Data can be removed at any time, either by the cache being flushed or the transients been cleaned up. Sites with multiple servers may use a shared cache or they may use a per server cache, for example, but even for single site servers they may be dropped during a deploy. As it's inherently unreliable, I don't think this is an approach we can take. |
|
Hey @mindctrl, I opened #11068 which builds on this same direction. Moved all sync storage to a dedicated table, with awareness in transients like your approach here. @peterwilsoncc's point about transient reliability is worth discussing — awareness data is transient by nature (cursor positions, selections) and repopulates on the next poll, so a cache flush just means a brief flicker rather than data loss. Happy to explore alternatives if that's still a concern. |
|
@peterwilsoncc thanks for reviewing. To be clear, I don't love this idea, but given how late we are in the cycle, I wanted to try to reduce the amount of postmeta db operations without refactoring a lot of code. I'd much prefer a custom table. Awareness syncing is the biggest "offender" here, because even when no content is changing and clients are idle, it's still updating the Since this is awareness state and not content data, it wouldn't be a lossy, destructive thing if the cache were cleared temporarily before the next awareness state sync, which would happen less than 1 second later. It would just appear that someone dropped offline very briefly. |
| * @param Closure(): T $callback Callback. | ||
| * @return T Return value from the callback. | ||
| */ | ||
| private function with_suspended_posts_last_changed_update( Closure $callback ) { |
There was a problem hiding this comment.
I see this is now only used in the add_update() method. Is it still even needed?
|
@mindctrl @westonruter Even as we explore a new table as our path forward, resolving the race condition in |
5 participants
This is a proof of concept for moving awareness state out of
wp_postmetato cache, using the Transients API, which will use object cache if available and fall back towp_optionsif not.I'm looking for feedback if this is a viable idea in general. If so, I can iterate on this to get it in better shape.
Edit: I branched this off @westonruter PR here: #11002
Trac ticket: https://core.trac.wordpress.org/ticket/64696
Use of AI Tools
I used Claude Opus 4.6 to help with this, mostly for the phpunit test.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.