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 --- .../src/meshbay_hub/static/transport.js | 36 ++++++++++++++++++++++ 1 file changed, 36 insertions(+) (limited to 'packages/meshbay-hub/src') diff --git a/packages/meshbay-hub/src/meshbay_hub/static/transport.js b/packages/meshbay-hub/src/meshbay_hub/static/transport.js index f7ae256..62ca2d9 100644 --- a/packages/meshbay-hub/src/meshbay_hub/static/transport.js +++ b/packages/meshbay-hub/src/meshbay_hub/static/transport.js @@ -2310,6 +2310,42 @@ class MeshBayTransport { return; } + // A bare `ack` answers three requests: sending a chat message, and storing + // or withdrawing a keypair bundle. The bundle acks name themselves in + // `detail`; the chat one carries nothing at all, so it was left to the + // arrival-order guess below — and that guess is wrong whenever anything + // else this browser asked for is still waiting. The ack went to *that* + // request, and the chat send waited out its own 30s timeout instead. + // + // What that looked like, and what this was found from: typing a message + // froze the Chat tab. The composer is disabled while a send is in flight, + // so it stopped accepting clicks and keys; the message never appeared; + // and it was there all along on the next visit to the tab, because the + // node had stored it and answered — into somebody else's promise. One + // unanswered request is enough, and an unanswered request is ordinary + // rather than exceptional: the node refuses an unknown file_id with a + // bare `error`, which names no request either and so reaches none, and a + // Videos tab that asked about a file the index no longer has leaves a + // `media_meta_req` sitting in `_pending` for the full 30s. + if (msg.type === 'ack') { + const named = msg.detail === 'keypair_bundle_stored' ? 'keypair_bundle_store' + : msg.detail === 'keypair_bundle_deleted' ? 'keypair_bundle_delete' + : null; + // Without a `detail` it is a chat ack — but a node that names neither + // is answering whichever of the three this browser has outstanding, so + // the reply is placed rather than dropped. + const wanted = named + ? [named] + : ['chat_msg', 'keypair_bundle_store', 'keypair_bundle_delete']; + for (const want of wanted) { + for (const [, handler] of this._pending) { + if (handler._reqType === want) { handler.resolve(msg); return; } + } + } + console.warn('[MeshBay] ack (detail=', msg.detail, ') with nothing waiting'); + return; + } + // Everything above is routed by something in the message. What is left is // matched by arrival order, which is only ever a guess — and a wrong guess // here hands one request's answer to another, which then waits for a reply -- cgit v1.2.3