Communication Services: Persistent 500 Errors When Reusing Rooms After Participant Changes — Investigation and Recommendations

Problem description

In Azure Communication Services Rooms, a PATCH /rooms/{roomId}/participants that removes a participant who is not in the room returns 200, but it adds that participant to the room with role Attendee. After that, GET /rooms/{roomId} returns 500 InternalServerError on every call, and users added to the room afterwards are rejected at join with 403, subCode 5828 ("not part of invitee list"). A call or a call restart is not needed to reproduce it. In our product this happens when the remove PATCH is sent twice for the same participant.

Environment

Resource ncxvideo-acs-dev-us, United States region. Rooms REST API version 2025-03-13 (raw REST, no SDK). Also seen with Java SDK com.azure:azure-communication-rooms 1.2.2. Operations: POST /rooms, PATCH /rooms/{roomId}/participants, GET /rooms/{roomId}, GET /rooms/{roomId}/participants.

What I've already tried

Minimal repro with raw REST:

1. Create identities H and X. Create a room with H as Presenter.
2. PATCH /rooms/{roomId}/participants with {"participants": {"<X rawId>": null}}. X was never in the room. Result: 200.
3. GET /rooms/{roomId}/participants: X is listed with role Attendee.
4. GET /rooms/{roomId}: 500.

Same result when the same remove PATCH is sent twice, one after the other: both return 200 and the participant comes back as Attendee. When the two PATCHes are sent at the same time, the second returns 409 and the room stays correct. Retrying GET /rooms/{roomId} does not help. One more remove PATCH for the unexpected Attendee repairs the room. Request ids and x-azure-ref values are in my previous email (rooms 99428999300596762 and 99492312097632926, 2026-10-07 UTC). The ApiRequestRooms metric returns no data for this resource, so I could not compare operations there.

Current status

We have a workaround in our code: we only send a remove PATCH for participants that are in the room. We do not need guidance on room reuse. We ask the Azure engineering team to answer:

• Is it expected that removing a participant who is not in the room adds it as Attendee? We expected 200 with no change, or 404.
• Why does GET /rooms/{roomId} return 500 when the room has such a participant?
• Why is a user added in this state rejected at join with 403/5828?