Follow-up from PR #278 skeptical review (Important #1).
Problem
present_invitation() writes to PRESENT_INVITATION_REQUEST and the App bridge effect routes it into receive_invitation — opening ReceiveInvitationModal with the full nickname-prompt accept flow. The URL-bar path and click-interceptor path both gate on is_invitation_processed(&inv.to_encoded_string()). The new in-app bridge does NOT.
For a previously-accepted-then-LeaveRoom'd room, clicking Accept on a stale invite card re-presents the full accept flow instead of recognising "you've already acted on this fingerprint." Mitigated when the room is still in ROOMS (button shows "Already a member" / disabled), but LeaveRoom removes from ROOMS while leaving the processed-hash entry.
Suggested fix
Gate the bridge effect in ui/src/components/app.rs:244 on is_invitation_processed(&inv.to_encoded_string()). If already processed, render a small toast ("you've already acted on this invite") instead of opening the modal.
Severity
Important UX, not a correctness bug. Recovery: accept the invite again proceeds to the standard already-a-member or pending-invite path. But the experience is confusing.
[AI-assisted - Claude]
Follow-up from PR #278 skeptical review (Important #1).
Problem
present_invitation()writes toPRESENT_INVITATION_REQUESTand theAppbridge effect routes it intoreceive_invitation— openingReceiveInvitationModalwith the full nickname-prompt accept flow. The URL-bar path and click-interceptor path both gate onis_invitation_processed(&inv.to_encoded_string()). The new in-app bridge does NOT.For a previously-accepted-then-
LeaveRoom'd room, clicking Accept on a stale invite card re-presents the full accept flow instead of recognising "you've already acted on this fingerprint." Mitigated when the room is still inROOMS(button shows "Already a member" / disabled), butLeaveRoomremoves from ROOMS while leaving the processed-hash entry.Suggested fix
Gate the bridge effect in
ui/src/components/app.rs:244onis_invitation_processed(&inv.to_encoded_string()). If already processed, render a small toast ("you've already acted on this invite") instead of opening the modal.Severity
Important UX, not a correctness bug. Recovery: accept the invite again proceeds to the standard already-a-member or pending-invite path. But the experience is confusing.
[AI-assisted - Claude]