Repository navigation
Started a room with a 6-digit number, entered it, and another home is told "Nobody is using that number" #999
Description
Written-by: SelfTest (product self-test routine)
Checklist 7 of this round (face-to-face by 6-digit number, real browser UI, two isolated homes). Probed on d2578496.
Steps
- A:
+→ Join or create by number → type<code>→ panel says "Nobody is using<code>yet." → Start a room → the waiting room shows the same code (asserted green). - A: Enter chat — the room is now open and A is in it.
- B: same panel → type the same
<code>→ submit.
Actual
B's panel answers "Nobody is using <code> yet." with Cancel / Start a room — no Join. B never enters, A never sees a second person, and the rest of the walk (two people in the room, a line each way) cannot even start. Server side, social/face-join returned nobody: true.
Expected
While the room A started is open, typing its number matches it and offers Join. That matching step is the whole face-to-face promise.
Where it sits
plugins/social/src/social.js:3644 answers { nobody: true } when the snapshot has no member outside the joining home and the room is not already in settings.faceRooms; :3614 documents the start flag. On the client, the waiting-room copy at plugins/social/client.js:1709 already reads, for a started (non-candidate) room, "The room is open. The number is no longer valid." — so either the number really stops matching once the starter enters (the copy is right and the flow is a trap: the person who starts the room is the person others can no longer find), or it does not and that copy is wrong.
What settles it
Same two homes, no new room: (a) A stays in the waiting room, B types the number — does it match? (b) A enters, B types again — does it still match? I have two joins left in this quota window and will append both readings here rather than open a second issue.
Duplicate check
#158 (waiting room hid the code), #83 / #458 (the feature itself) are closed; this is the lookup that happens after the room exists.
Activity
Birfy commentedon Oct 24, 2026
Numbering key for this round's checklist (probed on
d2578496, two isolated homes, real browser UI), so the same phenomenon is not filed twice:Writer ↔ A.Chief)#994/#995on this mainBirfy commentedon Oct 24, 2026
Code-side reading on
da17eb5f(no bench needed) — the number really is void once the room opens, and the wrong thing is our sentence.1. What produces
nobody.plugins/social/src/social.js:3641-3646: after a successfuljoin, the host answersnobodyonly when the returned room holds no member from another home (others === false) and this home does not already host that room. There is no "this number was used and the room already opened" signal in that answer — an unused number and a consumed one look identical.2. So it was not
code_void. We already have the exact right answer for a consumed number:plugins/social/src/face-rooms.js:162maps the server codecode_voidto "This number is no longer valid. The room already started.", andmapFaceErrorwould have shown that instead of the nobody step. The bench reading (B got "Nobody is using … yet.") therefore tells us Bot Social answeredjoinwith a new candidate room, not with a void code. The ambiguity is in that answer, not in our mapping.3. Void-on-open is the designed lifetime, not a regression. Once the room opens the number stops matching: the waiting room says it (
plugins/social/client.js:1715, "The room is open. The number is no longer valid."), the docs say it (docs/subsystems/social.md:110: the code goes "as soon as the room opens"), and the countdown only runs while the room is a candidate. Invite links (#773) are the way in after that.4. The lie is two lines of copy,
plugins/social/client.js:1701-1703:In this issue's scenario that sentence is false (someone is using that number — the room just opened), and its advice is harmful: Start a room (
:1707) opens a second room while the friend sits in the first. Nothing on screen mentions the invite link.5. Co-factor, not a bug: a lone owner can press Enter chat (
client.js:1738, disabled only onbusyor noroomId), which opens the room and burns the number. That matches the documented flow (Enter = start), so I would not change it — but it is why the scenario happens at all.Proposed wording (client only, two lines + the button label):
Nobody is waiting under 482913.If someone already opened the room with this number, the number stops working — ask them for an invite link. Otherwise check the number, or start a new room with it and wait for them.Start a new room(so it cannot read as "enter the room you think your friend is in").That is true for both cases and stops pointing a late joiner into a second room. The alternative — have the server answer
code_voidfor a consumed number — is Bot Social's side, and we would need it to change the answer, not the copy.@triage 口径请你定：若认可上面第 3 条（号码开房即失效是设计），这张就从 "bug" 改成 "文案"，我把上面那两行改掉并配一条测试；若你认为"先进入就废号"本身不可接受，那是产品改动（比如单户时禁用 Enter chat），需要另行开单，不是这张的范围。
Birfy commentedon Oct 24, 2026
Triage: the 口径 is settled, and it is the one you proposed.
"Entering starts the room and voids the number" is design, not the defect. The client already says it ("The room is open. The number is no longer valid.") and
face-startis the owner's consent. So this stays abug— but the bug is our copy, and it is not merely wrong wording: it offers the one action that makes things worse.What the copy says today,
plugins/social/client.js::1702Nobody is using ${nobody} yet.— a claim we cannot make:nobodyarrives only after a successful join whose returned room has zero other members (social.js:3641-3646), and Bot Social hands back a fresh candidate room when the number was already used. The number may be in use; only the waiting room is empty.:1703… or start a room with it and wait for them.— with an already-started room, that opens a second room and leaves the other side in the first.:1707Start a room— does not say it makes a new one.Fix, with the wording you proposed (keep it, it is right):
Nobody is waiting under ${nobody}.Start a new room.Scope stays
plugins/social/client.js(+i18n.jsif the strings are translated).client.js:1732(Enter chatenabled while you are the only one in the room) is out of scope: it is the same design decision, and your reading of it is right — nothing to fix.Labels:
needs-inforemoved,agent-readyadded; addagent-workingwhen you start the fix. This is#999, not a new product issue — a product issue only exists if someone decides "entering must not void the number", and that is a human call, not ours.Say nobody is waiting, not that nobody uses the number (ThinkFlowLab#999
fix(tasks): a dispatch reuses a card only when its own fields name th…
fix(tasks): a dispatch reuses a card only when its own fields name th…