[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):

 The pull request we've been working on renames everything from “sync” to
 “collaboration” - classes, REST routes, table name.  A deprecated `wp-
 sync/v1` route alias sticks around for backward compatibility with the
 Gutenberg plugin during its transition to `wp-collaboration/v1`.

 Here is how the pull request lines up with the proposed schema:

 —

 Items moved to the table:

 - `wp_sync_update` post meta - done, sync updates go into
 `wp_collaboration` rows instead of post meta.  This gets rid of the cache
 invalidation noise from `wp_cache_set_posts_last_changed()` firing on
 every write.

 Remaining where they currently are:

 - CRDT document - agreed, it’s only written on save, not on sync.  The
 pull request doesn’t touch that path.
 - Awareness - stored in transients rather than in the table.  Awareness
 data (cursor positions, selections) is high-frequency and short-lived -
 every active user writes it every few seconds, and entries go stale after
 30 seconds.  Transients handle this well: 60 second expiry, automatic
 cleanup when someone closes their tab.  Moving awareness into the table
 and adding an `event_type` column is worth exploring, but it adds write
 volume and index considerations we’d want to benchmark first. Proposing
 deferment for 7.1.

 Table name: `wp_collaboration` - matches. Registered in `wpdb` as
 `$wpdb->collaboration`.

 Columns:

 - `id` (BIGINT, unsigned, auto-increment, Primary key) - cursor for
 polling.  Auto-increment instead of `gmt_timestamp` because the beta 1-3
 post meta implementation uses millisecond timestamps as message IDs.  When
 two editors send updates in the same millisecond, they get the same  ID
 and one is silently dropped.  Auto-increment can’t collide, so that class
 of bug goes away.
 - `room` (VARCHAR, 255) - room identifier, unhashed since room strings
 like `postType/post:42` are short
 - `update_value` (LONGTEXT) - JSON-encoded update payload
 - `created_at` (DATETIME) - timestamp for the 7-day cleanup cron (matches
 autodrafts).  Expanding its use (admin UI, audit queries) fits naturally
 in 7.1.

 Composite index `KEY room (room, id)` - every hot query (idle poll, catch-
 up, compaction) filters by room first, then scans by `id`. Without this
 index those queries hit the full table.  Worth calling out since it’s not
 in the proposed schema but all three operations depend on it.

 `WP_Sync_Storage` renamed to `WP_Collaboration_Storage`.  Awareness
 methods are `get_awareness_state()` and `set_awareness_state()`.

 The PR includes a runnable proof of the beta 1-3 data loss bug and a
 performance benchmark covering idle poll, catch-up, and compaction from
 100 to 100,000 rows.

 Pull request description has been updated with the latest commands for
 testing:
 https://github.com/WordPress/wordpress-develop/pull/11068

 Props @mindctrl for flagging the timestamp collision risk and the
 importance of append-only writes.

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