[wp-trac] [WordPress Trac] #64887: Real-time collaboration: Compaction race condition in the default polling provider

[WordPress Trac]

#64887: Real-time collaboration: Compaction race condition in the default polling
provider
--------------------------+-----------------------------
 Reporter:  czarate       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  REST API      |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 There is a race condition in the post meta storage engine
 (`WP_Sync_Post_Meta_Storage`) for the default RTC polling provider.

 When handling compaction updates, all updates for a room are deleted
 before being partially restored along with the compaction update. The race
 condition is between these two lines:

 - https://github.com/WordPress/wordpress-
 develop/blob/8a82e67cf65766fcb8a11e3fe5c6e2f48083fcdb/src/wp-
 includes/collaboration/class-wp-sync-post-meta-storage.php#L305
 - https://github.com/WordPress/wordpress-
 develop/blob/8a82e67cf65766fcb8a11e3fe5c6e2f48083fcdb/src/wp-
 includes/collaboration/class-wp-sync-post-meta-storage.php#L308

 In other words, while Client A is performing compaction, Client B could
 contribute an update that gets lost because it is not in Client A's in-
 memory copy of the update set.

 Instead of using WordPress functions, we can use post meta `meta_id`s as
 cursors and conduct direct `DELETE` queries.

 Incidentally, moving to `meta_id` cursors also fixes a bug with 32-bit
 PHP. The current timestamp-based cursors exceed 32-bit integer space.


 Props to @mindctrl and @JoeFusco for spotting the race condition and
 exploring fixes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64887>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform