RTC: Return forbidden rooms together

[shekharnwagh]

What?

Closes #77243

Updates the HTTP polling sync endpoint and client so a multi-room request can handle all forbidden rooms from a single 403 response.

Why?

When a poll request includes multiple rooms the user cannot access, the server previously returned a 403 for only the first denied room. The client then had to retry once per forbidden room before reaching a stable working set, causing extra round trips and repeated 403 responses.

How?

• Collect all rooms that fail the sync permission check and return them in the REST error data as rooms.
• Keep the denied room names in the error message so older clients can still fall back to the existing message-matching behavior.
• Update the polling manager to unregister all denied rooms listed in error.data.rooms, while restoring pending updates for rooms that remain valid.
• Filter returned room names to the failed request payload so unrelated room names in an error response are ignored.
• Add JS coverage for multi-room forbidden responses and defensive filtering, plus PHP coverage for the REST error payload.

Testing Instructions

Run the polling-manager unit test:

npm run test:unit -- packages/sync/src/providers/http-polling/test/polling-manager.test.ts --runInBand

With wp-env-test running, run the sync server PHPUnit coverage:

vendor/bin/phpunit phpunit/tests/collaboration/wpHttpPollingSyncServer.php --filter test_sync_permission_checked_per_room

Manual two-collaborator check:

1. Start the local environment and enable collaboration:

npm run wp-env status
npm run wp-env start
npm run wp-env run cli wp option update wp_collaboration_enabled 1

2. In wp-admin, create a temporary user with the Editor role.
3. Make sure the active block theme's page template contains at least two template parts, such as Header and Footer. If it does not, add a second template part to the page template as an administrator.
4. Create or choose a Page that uses that template.
5. Open two separate browser sessions, such as a normal window and a private/incognito window.
6. In the first browser, log in as an administrator and open the Page.
7. In the second browser, log in as the temporary editor and open the same Page so there are two collaborators on the allowed page room.
8. In the temporary editor's browser, open DevTools, switch to the Network tab, and filter requests by wp-sync/v1/updates.
9. In the editor sidebar, switch to the Page tab, open the Template panel, click the template name, and toggle Show template on.
10. Confirm the temporary editor sees a single 403 response for /wp-sync/v1/updates where:

• the response code is rest_cannot_edit;
• data.status is 403;
• data.rooms contains all denied template/template-part rooms from that failed request, for example postType/wp_template_part:* rooms for Header and Footer;
• data.rooms does not contain the allowed Page room;
• message includes the denied room names for backwards compatibility with older clients.

11. Confirm later /wp-sync/v1/updates requests return to 200 responses instead of failing once per forbidden room.
12. Confirm the Connection lost modal does not appear and both browser sessions can keep editing the Page.

Testing Instructions for Keyboard

Not applicable. This PR does not change UI behavior.

Screenshots or screencast

Not applicable. This PR does not change UI behavior.

Use of AI Tools

AI assistance: Yes
Tool(s): OpenClaw, Codex
Used for: OpenClaw helped with writing code and Codex was used for PR description drafting.

[shekharnwagh]

@alecgeatches @maxschmeling Added the No Core Sync Required label because RTC has been removed from Core.

Does that seem like the right approach until RTC is added back to Core?

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: shekharnwagh <shekharnwagh@git.wordpress.org>
Co-authored-by: alecgeatches <alecgeatches@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[alecgeatches]

@tyxla Can you help us answer the question above?

Added the No Core Sync Required label because RTC has been removed from Core.

Does that seem like the right approach until RTC is added back to Core?

Here @shekharnwagh is making changes to the PHP RTC endpoint, but RTC was removed from core. Is the No Core Sync Required tag the right approach here until we get to 7.1? Thank you!

[alecgeatches]

I think we can remove identifyForbiddenRoom() fallback altogether as it's a string-parsing hack designed for the specific situation that'll be fixed here. We could want this for backwards compatibility on existing open tabs, but in that case the slower single-room unsubscriptions would work have already fired, so I think it's safe to leave out.

[shekharnwagh]

Removed in 0aec567

[alecgeatches]

Verified this works locally. I left one comment above about identifyForbiddenRoom which we should be able to remove altogether.

We can also wait to hear back about how we should tag PHP changes. Thank you for the fix!

[alecgeatches]

If we don't hear back about the No Core Sync Required label soon, I think it's probably right and you can merge this.

[tyxla]

@tyxla Can you help us answer the question above?

Added the No Core Sync Required label because RTC has been removed from Core.
Does that seem like the right approach until RTC is added back to Core?

That's correct. Even if you want, you can't really sync to core right now, as RTC is not in trunk anymore (see WordPress/wordpress-develop@73c3d9c and WordPress/wordpress-develop@a5905ab), and my understanding is that we potentially might move its development to a feature plugin instead of in WP core in the future.

But this also means that for most of the RTC work, while it remains in Gutenberg, it won't need to be in the 7.1 compat directory, but it can be in its own custom directory. That will also prevent receiving the core sync CI checks in the first place.

[shekharnwagh]

But this also means that for most of the RTC work, while it remains in Gutenberg, it won't need to be in the 7.1 compat directory, but it can be in its own custom directory. That will also prevent receiving the core sync CI checks in the first place.

I am going to go ahead and merge this for now, and the discussion about which directory to move this to can happen after this.