cli-setu 0.2.4 → 0.2.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cli-setu",
-  "version": "0.2.4",
+  "version": "0.2.5",
   "description": "Bridge your terminal to your phone — run and approve Claude Code, Codex CLI and other AI coding agents from anywhere.",
   "type": "commonjs",
   "bin": {

package/src/supervisor.js

@@ -544,25 +544,22 @@ function flushOutputBuffer() {
 
   // Still serialized against any send already in flight, so batches
   // themselves can never arrive out of order relative to each other.
+  // Real bug found by testing: the Backend used to AWAIT Azure's own
+  // sendToAll broadcast (~190-200ms per call, confirmed inherent to
+  // Azure Web PubSub's broadcast API, not fixable from our side) before
+  // responding here - since this chain won't send its next batch until
+  // this fetch() resolves, every Azure call directly delayed the next
+  // batch too, compounding into real, visible lag during a burst of PTY
+  // output. auth-server.js's /relay/terminal-output now responds
+  // immediately and broadcasts to Azure in the background, so this
+  // fetch() itself should resolve quickly regardless of Azure's own cost.
   sendInFlight = sendInFlight.then(async () => {
-    // TEMPORARY diagnostic (remove once the real lag source is found):
-    // measures the full fetch() round trip to the Backend, isolating "is
-    // the laptop's own network connection to the Backend slow" from
-    // Azure's broadcast time (measured separately, server-side, in
-    // auth-server.js's /relay/terminal-output handler) and from this
-    // batch's own BATCH_WINDOW_MS wait (not included here - that delay is
-    // intentional, not a bug).
-    const sendStart = Date.now();
     try {
       await fetch(`${AUTH_SERVER}/relay/terminal-output`, {
         method: 'POST',
         headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${deviceToken}` },
         body: JSON.stringify({ sessionId: SESSION_ID, seq: ++outputSeq, data: batch }),
       });
-      const sendMs = Date.now() - sendStart;
-      if (sendMs > 150) {
-        log(`[perf] terminal-output POST took ${sendMs}ms (bytes=${batch.length})`);
-      }
     } catch (err) {
       // A dropped terminal.output batch isn't fatal the way a dropped
       // confirmation would be - the next batch (or a fresh session.attach