@ouro.bot/cli 0.1.0-alpha.270 → 0.1.0-alpha.271

package/changelog.json

@@ -1,6 +1,12 @@
 {
   "_note": "This changelog is maintained as part of the PR/version-bump workflow. Agent-curated, not auto-generated. Agents read this file directly via read_file to understand what changed between versions.",
   "versions": [
+    {
+      "version": "0.1.0-alpha.271",
+      "changes": [
+        "fix(daemon): unblock daemon.stop deadlock that hung `ouro up` after a CLI auto-update. When the running daemon's version drifted from the local CLI version, `ensureDaemonRunning` would send `daemon.stop` over the socket, the daemon's command handler would `await this.stop()`, and `stop()` would `await server.close()`. server.close() resolves only after every open connection has closed — but the calling client's connection was the ONE thing keeping the server open: its `flushResponse()` was awaiting THIS function call. Both processes sat in kevent forever. Verified live on 2026-04-08: alpha.268 daemon hung at `daemon.server_end` log line for 5+ minutes after a fresh alpha.270 ouro process sent daemon.stop, and the alpha.270 ouro process hung waiting for the response. The deadlock had existed since the original `await server.close()` line was added (2026-03-05) but was masked for weeks by the half-close behavior in socket-client: the client called `client.end()` after writing its command, which (with `allowHalfOpen: false`) caused node to auto-tear-down the server's writable side, incidentally unblocking server.close() before the response was sent. The fix in #303/#334/#339 (which removed `client.end()` and switched to `allowHalfOpen: true` to stop dropping long-running responses like agent.senseTurn) accidentally exposed the underlying deadlock. Fix: don't `await` server.close() in stop() — just fire it. Once stop() returns, the daemon.stop case returns its response, flushResponse calls connection.end(response), the connection closes, and server.close()'s pending callback fires asynchronously. Includes a new daemon-stop-deadlock.test.ts that uses real net sockets to drive daemon.stop and asserts the response comes back within 2s — the test fails (24s timeout) without the fix and passes (110ms) with it."
+      ]
+    },
     {
       "version": "0.1.0-alpha.270",
       "changes": [

package/dist/heart/daemon/daemon.js

@@ -745,9 +745,36 @@ class OuroDaemon {
         await this.processManager.stopAll();
         await this.senseManager?.stopAll();
         if (this.server) {
-            await new Promise((resolve) => {
-                this.server?.close(() => resolve());
-            });
+            // DO NOT `await` server.close() here. server.close() resolves only
+            // after every open connection has closed. When stop() is invoked
+            // from the daemon.stop command handler, the calling client's
+            // connection is STILL open — its flushResponse() is currently
+            // awaiting THIS function. Awaiting close() creates a deadlock:
+            //
+            //   client → flushResponse → handleRawPayload → daemon.stop case
+            //   → stop() → await server.close() (waits for client's connection)
+            //   → client's connection waits for flushResponse to call
+            //     connection.end() → DEADLOCK
+            //
+            // Both processes sit in kevent forever. Verified live on
+            // 2026-04-08: alpha.268 daemon hung at `daemon.server_end` log
+            // line for 5+ minutes after a client sent daemon.stop, while the
+            // client (alpha.270 ouro up) hung waiting for the response.
+            //
+            // This regressed when #303/#334/#339 stopped half-closing the
+            // client socket and switched the server to allowHalfOpen: true.
+            // Previously, the client called .end() after writing its command,
+            // which (with allowHalfOpen: false) caused node to auto-tear-down
+            // the server's writable side — incidentally unblocking
+            // server.close() before the response was sent. The half-close
+            // breakage masked this deadlock; the fix exposed it.
+            //
+            // Solution: fire close() and let it complete asynchronously. Once
+            // stop() returns, the daemon.stop case returns its response,
+            // flushResponse() calls connection.end(response), the connection
+            // closes, and server.close()'s pending callback fires. The event
+            // loop drains and the daemon exits cleanly.
+            this.server.close();
             this.server = null;
         }
         /* v8 ignore start -- outlookServer stop: only reachable when the outlook HTTP server successfully bound to port 6876 during start(). Coverage fluctuates locally because a running production daemon holds the port and tests get EADDRINUSE, leaving outlookServer null. In CI the port is free and this block runs. Not worth fighting port contention to cover two trivial lines. @preserve */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ouro.bot/cli",
-  "version": "0.1.0-alpha.270",
+  "version": "0.1.0-alpha.271",
   "main": "dist/heart/daemon/ouro-entry.js",
   "bin": {
     "cli": "dist/heart/daemon/ouro-bot-entry.js",