[wp-trac] [WordPress Trac] #64696: Real time collboration effectively disables persistent post caches while anyone edits a post

[WordPress Trac]

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by JoeFusco):

 With the decision to ship RTC as opt-in for RC1
 ([https://wordpress.slack.com/archives/C07NVJ51X6K/p1773850504196589 Slack
 announcement]), I'd like to share some context on the remaining open
 question: whether to proceed with the dedicated table.

 @ellatrix, thank you for putting together a patch to explore the post meta
 direction. Before adding a table, we should be sure post meta can't do the
 job. The cache invalidation fix addresses 1 of the 3 known issues that
 surfaced during development. The other two sit deeper in how post meta
 handles this access pattern: the compaction race condition that @czarate
 documented in comment:85 and [https://github.com/WordPress/wordpress-
 develop/pull/11067 PR #11067] can silently drop updates when concurrent
 writes overlap, and cursor ID collisions can occur when those writes land
 within the same millisecond. @peterwilsoncc walked through the scope of
 what the Meta API and `WP_Meta_Query` changes would require in comment:86,
 each touching shared infrastructure that every plugin in the ecosystem
 relies on.

 The table resolves all three issues in one place. Append-only writes with
 auto-increment IDs eliminate both the compaction race and the collision
 window structurally. The blast radius is limited to RTC - nothing else in
 core is affected. And the compaction bug that @czarate identified needs to
 be fixed regardless of direction. With the table, it already is.

 The data stored in this table is entirely ephemeral - session state, not
 user content. If the schema needs to evolve in 7.1, we can alter or
 rebuild the table without any meaningful data loss.
 `wp_is_collaboration_enabled()` requires both the site option and
 `db_version >= 61841`, so if the database upgrade hasn't run yet, on
 multisite or anywhere else, RTC simply doesn't activate. Sites that don't
 opt in never create or query the table.

 ----

 The implementation is tested (unit + E2E), feature-gated, and isolated
 from core's shared APIs.  Could use feedback on the supporting tests to
 ensure we captured all relevant scenarios.

 https://github.com/WordPress/wordpress-develop/pull/11256

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64696#comment:95>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform