git-watchtower 2.1.11 → 2.1.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "git-watchtower",
-  "version": "2.1.11",
+  "version": "2.1.13",
   "description": "Terminal-based Git branch monitor with activity sparklines and optional dev server with live reload",
   "main": "bin/git-watchtower.js",
   "bin": {

package/src/server/coordinator.js

@@ -34,6 +34,18 @@ const WATCHTOWER_DIR = path.join(os.homedir(), '.watchtower');
  */
 const MAX_IPC_BUFFER = 1024 * 1024;
 
+/**
+ * Maximum number of concurrent worker connections the coordinator will
+ * accept. The legitimate ceiling is "one git-watchtower instance per
+ * project the user is actively working on" — a generous double-digit
+ * limit covers any real workflow. The cap exists so a buggy or
+ * malicious local process running as the same user can't open thousands
+ * of sockets and exhaust the coordinator's file descriptors. Beyond
+ * this limit, Node's net.Server closes incoming connections after
+ * accept() rather than handing them to the request listener.
+ */
+const MAX_WORKER_CONNECTIONS = 64;
+
 /**
  * How long a worker waits for a `registered` ACK from the coordinator
  * after the TCP connection completes and the `register` frame is written.
@@ -255,6 +267,12 @@ class Coordinator {
         this._handleWorkerConnection(socket);
       });
 
+      // Cap concurrent connections so a buggy/malicious local peer can't
+      // exhaust our FDs by opening thousands of sockets. Node's net.Server
+      // honours this by closing the accepted socket immediately when the
+      // count exceeds the limit — request listener never runs.
+      this.ipcServer.maxConnections = MAX_WORKER_CONNECTIONS;
+
       this.ipcServer.on('error', (err) => {
         reject(err);
       });
@@ -722,4 +740,5 @@ module.exports = {
   LOCK_FILE,
   SOCKET_PATH,
   MAX_IPC_BUFFER,
+  MAX_WORKER_CONNECTIONS,
 };

package/src/server/web.js

@@ -564,7 +564,14 @@ class WebDashboardServer {
       try {
         client.write(message);
       } catch (e) {
-        // Dead client — will be cleaned up on 'close'
+        // Write failed — proactively prune the dead client instead of
+        // waiting for req.on('close') to fire. On abrupt socket resets
+        // 'close' can be delayed long enough that subsequent frames
+        // hit the same failed write, accumulating exception work and
+        // keeping clientCount misleadingly high. Set.delete during
+        // iteration is safe; the for-of iterator handles it.
+        try { client.end(); } catch (_) { /* already torn down */ }
+        this.clients.delete(client);
       }
     }
   }