Suggestions: Adopt synced apply of a pending-remove instead of re-tagging

When another client accepts a pending-remove suggestion, the
marker-clear plus the removeBlock arrive on this client through sync,
typically batched into a single block-editor update. The interceptor's
removal-detection branch was treating the disappearance as a fresh
user delete — re-inserting the block and tagging it pending-remove
again, which then bounced back through sync and undid the apply on
the accepting client a moment after they clicked.

Recognize the apply landing by checking the previous-tick tree
snapshot for `metadata.suggestion.type === 'pending-remove'` on the
disappearing block. When the marker is still there, drop the snapshot
entry and let the removal stand.

The PRUNE_ORPHANS effect in overlay-context cleans up the matching
overlay entry on the next render.

Author: adamsilverstein

packages/editor/src/components/suggestion-mode/store-interceptor.js

@@ -634,6 +634,27 @@ export default function SuggestionStoreInterceptor() {
 			const removedIds = [];
 			for ( const clientId of tree.blocksByClientId.keys() ) {
 				if ( ! live.has( clientId ) ) {
+					// "Apply landing": when another client accepts a
+					// `pending-remove` suggestion, the resulting
+					// `removeBlock` arrives here through sync —
+					// typically batched with the marker-clearing
+					// `updateBlockAttributes` into a single block-
+					// editor update, which fires this subscriber
+					// once. The previous-tick tree snapshot still
+					// carries the pending marker, so we can recognize
+					// the disappearance as the apply landing rather
+					// than a fresh user delete. Adopt the removal:
+					// drop the snapshot entry and skip the re-insert
+					// + re-tag path. Without this, the apply bounces
+					// back through sync and undoes the removal on the
+					// accepting client a moment after they clicked.
+					const trackedMarker =
+						tree.blocksByClientId.get( clientId )?.attributes
+							?.metadata?.suggestion?.type;
+					if ( trackedMarker === 'pending-remove' ) {
+						snapshot.delete( clientId );
+						continue;
+					}
 					removedIds.push( clientId );
 				}
 			}

packages/editor/src/components/suggestion-mode/test/store-interceptor.js

@@ -427,6 +427,57 @@ describe( 'SuggestionStoreInterceptor (integration)', () => {
 		);
 	} );
 
+	it( 'adopts a removal that arrives bundled with its marker-clear (apply of pending-remove via sync)', async () => {
+		// Regression: when another client clicks "Apply" on a
+		// pending-remove suggestion, the resulting marker-clear and
+		// removeBlock land here through sync as a single batched
+		// block-editor update. Without the apply-landing check the
+		// removal-detection branch would re-insert the block and tag
+		// it as a fresh pending-remove — which then bounces back
+		// through sync, undoing the apply on the accepting client a
+		// moment after they clicked.
+		const a = createBlock( TEST_BLOCK_NAME, { content: 'A' } );
+		const b = createBlock( TEST_BLOCK_NAME, { content: 'B' } );
+		const { registry, getOverlay } = setup( {
+			initialBlocks: [ a, b ],
+		} );
+
+		// First, this client creates the pending-remove suggestion
+		// (just like the suggester would).
+		await act( async () => {
+			registry.dispatch( blockEditorStore ).removeBlock( b.clientId );
+		} );
+		await flushSubscribers();
+
+		expect(
+			registry.select( blockEditorStore ).getBlockAttributes( b.clientId )
+				?.metadata?.suggestion?.type
+		).toBe( 'pending-remove' );
+
+		// Simulate the apply landing: marker-clear + removeBlock
+		// batched into a single store update (matching how YJS
+		// applies multi-op transactions on a peer client).
+		await act( async () => {
+			registry.batch( () => {
+				registry
+					.dispatch( blockEditorStore )
+					.updateBlockAttributes( b.clientId, { metadata: {} } );
+				registry.dispatch( blockEditorStore ).removeBlock( b.clientId );
+			} );
+		} );
+		await flushSubscribers();
+
+		// The block must stay removed — the interceptor adopts the
+		// apply landing rather than re-inserting and re-tagging.
+		const liveBlocks = registry.select( blockEditorStore ).getBlocks();
+		expect( liveBlocks ).toHaveLength( 1 );
+		expect( liveBlocks[ 0 ].clientId ).toBe( a.clientId );
+
+		// The orphan overlay entry is cleaned up by the PRUNE_ORPHANS
+		// effect once the block leaves the live tree.
+		expect( getOverlay().entries[ b.clientId ] ).toBeUndefined();
+	} );
+
 	it( 're-inserts only the top-level removed block when a parent and its child are removed together', async () => {
 		// `removeBlock` on a parent removes the whole subtree atomically.
 		// We must re-insert just the parent — its child rides along.