From e7b699b59acb19562c698f11bd212a1e0c6b8f3a Mon Sep 17 00:00:00 2001 From: ispyisail Date: Fri, 2 Oct 2026 11:15:15 +1300 Subject: [PATCH] Live mode: close each connection once it is answered The qet MCP server connects once per request. On Windows a named pipe's disconnection reaches QLocalSocket late, so the second of two quick calls was turned away as "another assistant is already connected". Found testing the Windows package under Wine with a Windows-side client. Co-Authored-By: Claude Opus 5.5 (1M context) --- sources/scripting/liveserver.cpp | 9 +++++++++ sources/scripting/liveserver.h | 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/sources/scripting/liveserver.cpp b/sources/scripting/liveserver.cpp index 42419c50c..c7806fd3d 100644 --- a/sources/scripting/liveserver.cpp +++ b/sources/scripting/liveserver.cpp @@ -254,6 +254,15 @@ void LiveServer::handle(const QJsonObject &request) if (request.contains(QStringLiteral("id"))) answer.insert(QStringLiteral("id"), request.value(QStringLiteral("id"))); send(answer); + //One request per connection: close it from this side once it is + //answered. Waiting for the client to hang up raced the next + //request on Windows, where a named pipe's disconnection reaches + //QLocalSocket late -- the second call of a quick pair was turned + //away as "another assistant" (found under Wine, 2026-10-02). + if (m_client) { + m_client->disconnectFromServer(); + m_client = nullptr; + } emit handled(request, answer); } diff --git a/sources/scripting/liveserver.h b/sources/scripting/liveserver.h index 7bf4db57d..60f47e8c7 100644 --- a/sources/scripting/liveserver.h +++ b/sources/scripting/liveserver.h @@ -40,8 +40,8 @@ class QWidget; The channel is a QLocalServer only the user's own account can open, with a random name and token written to live-session.json in the data folder, which the MCP server reads; the file goes when the channel - closes. One request per line, one answer per line, both JSON; every - request carries the token. + closes. One JSON request per connection, one JSON answer back, then + the server closes the connection; every request carries the token. Requests are never handled inside the socket's readyRead: each is queued to the event loop first. QETApp::receiveMessage() learnt why --