From 691c6ba4ef51085c89aeddbcabd5c733861eb56b Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Thu, 3 Sep 2026 12:13:41 +0200 Subject: fix(hub): route the chat ack to the request that asked for it Typing a message froze the Chat tab: the composer stopped taking clicks and keystrokes, the message never appeared, and it was there all along on the next visit to the tab. The node answers a chat message with a bare {"type": "ack"} -- no request id, no type of its own -- so _dispatch had nothing to match it on and left it to the arrival-order guess at the end of the function. That guess is wrong the moment anything else this browser asked for is still waiting: the ack went to *that* request, and the chat send waited out _sendAndWait's own 30s timeout. Since the composer is disabled while a send is in flight, that reads as a frozen tab; the node had stored the message and answered, into somebody else's promise. An outstanding request is the ordinary case, not a rare one. The node refuses an unknown file_id with a bare `error`, which names no request either and so reaches none, leaving the Videos tab's media_meta_req in _pending for the full 30s. That is the one that was live when this was found. - `ack` is now matched by request type: chat_msg, or the keypair-bundle store and delete, which name themselves in `detail`. A node naming neither still has its reply placed rather than dropped. Every line of chat-app.js is correct and every routed message in transport.js is routed correctly -- the defect is in the seam, so tests/harness/ chat_send_probe.py drives the two together: the real ChatPanel over the real MeshBayTransport, with only the DataChannel replaced by a stand-in answering what the node answers. test_chat_send.py asserts against it, and with the fix reverted all three of its tests fail on the three visible halves of the defect -- the composer still disabled, the message absent, and the ack resolving the unrelated request. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01GFF4BL8VSKrghkSLzCrTVs --- packages/meshbay-hub/tests/test_chat_send.py | 73 ++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 packages/meshbay-hub/tests/test_chat_send.py (limited to 'packages/meshbay-hub/tests/test_chat_send.py') diff --git a/packages/meshbay-hub/tests/test_chat_send.py b/packages/meshbay-hub/tests/test_chat_send.py new file mode 100644 index 0000000..4224fdb --- /dev/null +++ b/packages/meshbay-hub/tests/test_chat_send.py @@ -0,0 +1,73 @@ +""" +Sending a chat message must come back. + +The node answers a chat message with a bare `{"type": "ack"}` — no request id, +no type of its own — so `_dispatch` had nothing to match it on and left it to +the arrival-order guess at the end of the function. That guess is wrong as soon +as anything else this browser asked for is still waiting: the ack was handed to +*that* request, and the send waited out `_sendAndWait`'s 30s timeout. Since the +composer is disabled while a send is in flight, the Chat tab stopped taking +clicks and keys, the message never appeared — and it was there on the next +visit, because the node had stored it and answered. + +An outstanding request is the ordinary case, not a rare one: the node refuses +an unknown file_id with a bare `error`, which names no request either, so a +Videos tab that asked about a file the index no longer has leaves a +`media_meta_req` in `_pending` for a full 30s. + +None of that 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. +""" +import json +import shutil +import subprocess +from pathlib import Path + +import pytest + +HARNESS = Path(__file__).parent / "harness" / "chat_send_probe.py" +STATIC = Path(__file__).resolve().parents[1] / "src" / "meshbay_hub" / "static" + +pytestmark = pytest.mark.skipif( + shutil.which("google-chrome") is None or not (STATIC / "chat-app.js").exists(), + reason="Chrome or the SPA sources are not available") + + +@pytest.fixture(scope="module") +def probe(): + run = subprocess.run(["python3", str(HARNESS)], capture_output=True, timeout=180) + assert run.returncode == 0, run.stderr.decode()[-2000:] + data = json.loads(run.stdout.decode()) + return data, {s["label"]: s for s in data["steps"]} + + +def test_the_composer_comes_back(probe): + """The one thing a person sees: the tab is usable again.""" + _, steps = probe + assert steps["stale request pending"]["composerDisabled"] is False, ( + "the composer was already unusable before the send") + assert steps["after send"]["composerDisabled"] is False, ( + "the composer is still disabled well inside the 30s request timeout -- " + "the send never came back, which is what reads as a frozen Chat tab") + + +def test_the_message_is_displayed(probe): + """A sent message appears at once, not on the next visit to the tab.""" + _, steps = probe + before = steps["stale request pending"]["bubbles"] + assert steps["after send"]["bubbles"] == before + 1, ( + "the message was not added to the conversation") + assert steps["after send"]["lastText"] == "hello" + assert steps["after send"]["composerValue"] == "", ( + "the text came back into the composer, so the send was treated as failed") + + +def test_the_ack_is_not_handed_to_another_request(probe): + """The other half of the same defect: whatever was waiting got the ack and + carried on with a reply to a question it never asked.""" + data, _ = probe + assert "media_meta resolved with ack" not in data["log"], ( + "the chat ack was routed to the pending media_meta_req -- that request " + "now believes it has an answer, and the chat send is waiting for a " + "reply that already arrived") -- cgit v1.2.3