From 375ad7d0435a176ad593a32045a5f0182a36d505 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sun, 20 Sep 2026 18:56:58 +0200 Subject: fix: removing someone who never redeemed their invitation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A member row appears only when a code is consumed, so revoking someone invited to the wrong group was refused for having no row — and the node's refusal aborted the browser's removal before its hub half, leaving them a member everywhere with a live code. Revoking now cancels unredeemed codes for that group, and a node refusal no longer cancels the hub removal. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index f0f90d5..928d526 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -438,6 +438,25 @@ do. Read them before writing anything that touches the same mechanism. waits for a reply already delivered elsewhere. A reply needs an identifier the protocol guarantees, not a field it happens to have +- **One errand, two halves, and the first one's refusal cancelled the second.** + Removing a member is the node half (stop wrapping the group key) then the hub + half (stop them reaching the node at all), in that order because it fails + safe. The node call was not guarded, so anything it refused ended the whole + callback — and it refused the commonest case there is: a person invited to + the wrong group has no member row on the node, only an unredeemed code, so + `set_status` matched nothing and answered "no such member in that group". + The removal never reached the hub. They stayed a member in the list (the hub + answers it), in the owner's other sessions and in the administrator's view, + the code emailed to them stayed live for its seven days, and the interface + offered no second way to take back either — the same button, every time, + reporting that the person it was listing was not there. Two rules, and the + second is the one that generalises: **a half that only ever removes access is + not the half to skip when the other is in doubt** — report the refusal after + doing what can be done, never instead of it; and **an operation that is + refused for the state it was invented to fix is not a refusal, it is a + missing case**. `test_member_removal.py` holds the seam, and the node tests + hold the case + - **A refusal that never rejects.** Denying Chromium's `fullscreen` permission does not make `requestFullscreen()` throw — the promise never settles. The deny-everything handler was written from a true sentence ("nothing here needs -- cgit v1.2.3