Failure modes, race conditions and abuse scenarios across the live-chat, session, link and admin flows — and how ORISO is designed to handle each.
Each edge case below has a trigger, an expected behaviour, and a risk if mishandled. Most are direct echoes of the issues raised in the Frank↔Nikunj huddle.
Heartbeat lost → session → Paused; if no resume in 5 min → Ended; Megolm keys lost from client side; counselor still sees the chat history (≤ 48 h); session metadata anonymized; client cannot re-enter
Risk if mishandled
Counselor stuck with a "ghost" active session blocking their availability
Test
Active chat → close tab → counselor sees "client disconnected" within 5 min
Direct Figma question: "what happens when a user deletes himself during a video call (if he is the initiator)"
Trigger
A client is the initiator of an active LiveKit call and clicks "Konto löschen" / closes their tab during the call
Expected
(1) LiveKit session continues for remaining counselors. (2) Initiator role transfers to the next counselor by joined_at ASC. (3) The client's pseudonym is wiped within ~90 s. (4) System message in chat: "Ein Teilnehmer hat das Gespräch verlassen." (5) If no counselor remains in the room, LiveKit ends the call gracefully and the chat returns to text-only state.
Risk if mishandled
Counselors stuck on a frozen call; client identity persists past disconnect; LiveKit room becomes a billing leak.
Test
E2E: client initiates call → client deletes self → call survives among counselors; if last person leaves, call dies; client identity wiped.
Direct Figma question: "What happens if a client deletes himself from a group chat?"
Trigger
A client clicks "leave group" or deletes their account while in a group room
Expected
(1) Pseudonym wiped immediately. (2) Their existing messages remain in the room with author label "Ehemaliger Teilnehmer" — bodies stay E2EE; pseudonym is no longer linked to a Keycloak user. (3) System message "{pseudonym} hat den Chat verlassen." (4) If the client was the only advice-seeker in the group, the room is auto-archived and counselors notified. (5) If other clients remain, the group continues normally.
Risk if mishandled
Client identity lingers in a group; or messages disappear and the group context becomes confusing.
Test
E2E: 1 client + 2 counselors group → client leaves → counselors see system message + author label change; group persists.
Email is stored encrypted, visible only to Platform Admin; counselors do not see it; first verification email is sent; future notifications mirror to email
Risk if mishandled
Counselor sees the client's email in any UI surface
Keycloak consultant role exists but the user has no ConsultantAgency row
Expected
The user is invisible on the app layer (per huddle: "a counselor is not visible without a counseling center"); their dashboard shows an info banner asking to be assigned
Risk if mishandled
Tickets can never reach this counselor; or worse, they appear in the queue but cannot be picked up
A supervisor-consultant invites themselves to a colleague's room
Expected
System message visible to all members: "Supervisor X has joined for QA review"; audit row written; supervisor can read messages but appears in the participant list
All centers under that tenant become read-only; counselors cannot accept new tickets; existing active sessions are allowed to finish; live-chat links return "currently unavailable"; tenant data preserved (not deleted)