diff options
Diffstat (limited to 'packages/meshbay-hub/tests')
| -rw-r--r-- | packages/meshbay-hub/tests/harness/chat_send_probe.py | 63 | ||||
| -rw-r--r-- | packages/meshbay-hub/tests/test_chat_send.py | 68 |
2 files changed, 128 insertions, 3 deletions
diff --git a/packages/meshbay-hub/tests/harness/chat_send_probe.py b/packages/meshbay-hub/tests/harness/chat_send_probe.py index 28635b0..2df12e3 100644 --- a/packages/meshbay-hub/tests/harness/chat_send_probe.py +++ b/packages/meshbay-hub/tests/harness/chat_send_probe.py @@ -36,6 +36,18 @@ Both are run with an older request already pending — the condition that turns "guess by arrival order" from usually-right into wrong — and both must come back inside a second and a half. +A third scenario, `reconnect`, is about the *other* way this tab freezes, and +the one no timeout ends: + + `reconnect` the connection is untouched, but its **device identity** is + cleared and settled again, which is what every reconnect does to + it — `connect()` drops it on the way in and `device_hello` + restores it on the way out. The composer gates on that identity, + and used to read it off the transport during render, where a ref + changing re-renders nothing: it latched shut on whatever + unrelated re-render came next (a message arriving) and had no + event that would open it again. + Since MNP 2.0 a send also has to **seal and sign for real** before it goes anywhere, so this drives `chatKeys()`, `openGroup`, `sealChat` and a genuine Ed25519 signature rather than a model of any of them. The device key is @@ -110,7 +122,7 @@ PAGE_TEMPLATE = r"""<!doctype html><html><head><meta charset=utf-8> <script src="/keyderive.js"></script> <script src="/transport.js"></script> <script type="module"> -import { html, render, useRef } from '/vendor/htm-preact.js'; +import { html, render, useRef, useState, useEffect } from '/vendor/htm-preact.js'; import { ChatPanel } from '/chat-app.js'; const log = []; @@ -192,11 +204,23 @@ function makeTransport(name, chatReply) { return tp; } +// Stands in for group-page.js the way the stub above stands in for the node, +// and for the same reason: what is under test is the seam between them. These +// are its three lines — state, the callback wired before connect() runs, and +// the prop — because the defect was that ChatPanel read `devicePk` off the +// transport during render instead, and a ref changing re-renders nothing. function Host({ tp }) { const transportRef = useRef(tp); const gekRef = useRef(null); + // Seeded from the transport because makeTransport hands over a connection + // whose handshake is already done; in the page the callback below is what + // sets it, since it is wired before connect() and connect() is where + // device_hello runs. + const [deviceReady, setDeviceReady] = useState(!!tp.devicePk); + useEffect(() => { tp.onDeviceIdentity = (ok) => setDeviceReady(ok); }, [tp]); return html`<${ChatPanel} transportRef=${transportRef} gekRef=${gekRef} - username="me" userId="user-me" entries=${[]} status="connected" />`; + username="me" userId="user-me" entries=${[]} status="connected" + deviceReady=${deviceReady} />`; } function typeInto(root, text) { @@ -208,7 +232,7 @@ function typeInto(root, text) { c.dispatchEvent(new Event('input', { bubbles: true })); } -async function runScenario(name, chatReply) { +async function runScenario(name, chatReply, duringSession) { const root = document.createElement('div'); document.getElementById('root').appendChild(root); const tp = makeTransport(name, chatReply); @@ -225,6 +249,10 @@ async function runScenario(name, chatReply) { // a send is in flight. composerDisabled: c ? c.disabled : null, composerValue: c ? c.value : null, + // Which of the composer's two reasons it is. "Disabled" alone was all + // the field report could say, and it is the half that does not identify + // the defect. + composerPlaceholder: c ? c.placeholder : null, pending: tp._pending.size, }); }; @@ -241,6 +269,8 @@ async function runScenario(name, chatReply) { await wait(100); snap('older request pending'); + if (duringSession) await duringSession(tp, snap); + typeInto(root, 'hello'); await wait(100); root.querySelector('.chat-input').dispatchEvent(new KeyboardEvent('keydown', @@ -259,6 +289,33 @@ async function runScenario(name, chatReply) { out.scenarios.push(await runScenario('ack', { type: 'ack', v: '0.14' })); out.scenarios.push(await runScenario( 'error', { type: 'error', detail: 'Request failed' })); + // The connection survives, the device identity does not — which is exactly + // what a reconnect does: connect() clears it on the way in and device_hello + // settles it again on the way out. Nothing about the channel changes, so + // nothing else in the page moves, and the composer has to follow this on its + // own or it never comes back. + out.scenarios.push(await runScenario( + 'reconnect', { type: 'ack', v: '0.14' }, + async (tp, snap) => { + tp._setDevicePk('', 'new connection'); + await wait(100); + snap('device identity cleared'); + // A live message arrives — the ordinary thing that re-renders this + // panel, and the step that made the old defect permanent. The composer + // read `devicePk` off the transport during render, so it went disabled + // *here*, on an unrelated re-render, long after the identity was + // actually lost; and since nothing re-rendered it when the identity came + // back, it stayed that way for the rest of the session. + if (tp._onChat) { + tp._onChat({ id: 'live-1', sender_id: 'someone', sender_name: 'someone', + payload: 'still there?', timestamp: now, verified: true }); + } + await wait(100); + snap('a message arrived meanwhile'); + tp._setDevicePk(DEVICE_PK_B64, 'device_hello_ack'); + await wait(100); + snap('device identity restored'); + })); fetch('/log', { method: 'POST', body: JSON.stringify(out) }); })(); </script></body></html>""" diff --git a/packages/meshbay-hub/tests/test_chat_send.py b/packages/meshbay-hub/tests/test_chat_send.py index 5db8f26..d442383 100644 --- a/packages/meshbay-hub/tests/test_chat_send.py +++ b/packages/meshbay-hub/tests/test_chat_send.py @@ -24,6 +24,13 @@ shapes of answer. None of it is visible in `chat-app.js`, where every line is correct, so this drives the real panel over the real transport in a browser rather than reading either source. + +Since 2026-09-09 it covers a **second** way the tab freezes, found from a field +report and reproduced here: a reconnect clears the connection's device identity +and settles it again, and the composer gates on that. Nothing announced the +change, so the panel latched shut on an unrelated re-render and had no event +that would open it again. Unlike the routing defect above, no timeout ends it — +only leaving the group or restarting the client does. """ import json import shutil @@ -147,6 +154,67 @@ def test_the_chat_keys_answer_is_not_handed_to_another_request(probe): "send then waits out its own 30s timeout with the composer disabled") +def test_a_reconnect_gives_the_composer_back(probe): + """ + The other way a Chat tab freezes, and the one no timeout ever ends. + + A send that goes astray holds the composer for 30s. This holds it for the + rest of the session: `devicePk` — "this connection identified a device to + the node" — is settled inside `connect()`, so every reconnect clears it and + re-settles it, and the composer gates on it. Nothing announced the change, + so the panel went disabled on whatever unrelated re-render happened next + (a message arriving) and had no event that would bring it back. The + connection stayed perfectly healthy throughout, no request ever timed out, + and nothing reached the console: a field report of exactly this arrived + with a full console dump that could not say what had happened. + + The three states below are the whole claim: it closes when the identity + goes, it stays closed while it is gone, and it **opens again** when the + identity comes back. + """ + _, steps = probe + sc = steps["reconnect"] + assert sc["older request pending"]["composerDisabled"] is False, ( + "the composer was already unusable before the reconnect") + assert sc["device identity cleared"]["composerDisabled"] is True, ( + "the composer stayed open with no device identity to seal with -- the " + "send would be refused with no reason on screen") + assert sc["a message arrived meanwhile"]["composerDisabled"] is True, ( + "an unrelated re-render changed the answer, which means the answer was " + "never being derived from anything the panel was told about") + assert sc["device identity restored"]["composerDisabled"] is False, ( + "the composer never came back after the reconnect re-identified the " + "device -- this is the freeze that no timeout ends and that only " + "leaving the group or restarting the client clears") + + +def test_the_closed_composer_says_which_of_its_two_reasons_it_is(probe): + """ + A disabled textbox is one symptom with two causes — a send in flight, or no + device identity — and telling them apart is what the field report could not + do. The placeholder is where a person reads the difference. + """ + _, steps = probe + sc = steps["reconnect"] + assert sc["device identity cleared"]["composerPlaceholder"] \ + == "chat.encrypted_cannot_send", ( + "a closed composer offered no reason for being closed") + assert sc["device identity restored"]["composerPlaceholder"] \ + == "chat.placeholder" + + +def test_sending_works_again_after_a_reconnect(probe): + """Not just enabled — actually able to seal and send under the identity + the reconnect settled on.""" + _, steps = probe + sc = steps["reconnect"] + before = sc["device identity restored"]["bubbles"] + assert sc["after send"]["bubbles"] == before + 1, ( + "the message was not added to the conversation after the reconnect") + assert sc["after send"]["composerValue"] == "", ( + "the text came back into the composer, so the send failed") + + def test_history_still_renders(probe): """ Not about sending at all, and here because it broke without a sound: |