jefrichat-mcp 0.48.8 → 0.48.9

package/dist/http.js

@@ -60682,8 +60682,48 @@ var JefriClient = class _JefriClient {
   // heartbeat: did we get a pong since the last ping?
   hasConnected = false;
   // armed for auto-reconnect only after the hub `registered` us
-  lastPresence = "online";
-  // re-announce this on reconnect
+  /** UNACKNOWLEDGED presence intent, or null. Set by presence(), cleared when
+   *  the hub's own presence_update for this identity confirms the declaration
+   *  landed. Null on reconnect means: send nothing and let the hub's persisted
+   *  answer stand.
+   *
+   *  Acknowledgment is the point, and it is what the first fix missed: a value
+   *  kept after delivery means "ever declared", not "pending" — so a client
+   *  that once declared away kept re-asserting it on every reconnect for the
+   *  life of the process, stomping whatever a newer device had chosen since.
+   *  The same stale-overwrite, one level down. */
+  pendingPresence = null;
+  /** The self statusRev BASELINE captured when the pending declaration was made.
+   *  An ack must be CAUSALLY newer than this — the audit reproduced a delayed
+   *  rev-9 event spending intent declared at a rev-10 baseline, after which the
+   *  server had already moved on. Identity + status matching alone cannot order
+   *  events; the revision can. */
+  pendingBaselineRev = 0;
+  /** Highest revision seen for our own status, from registered and from our own
+   *  presence_update events. */
+  selfStatusRev = 0;
+  /** Would a reconnect re-send a presence frame? True only while a declaration
+   *  is UNACKNOWLEDGED. Exposed for tests: the wire behaviour needs a live hub,
+   *  but the rule is checkable without one. */
+  wouldReassertPresence() {
+    return this.pendingPresence !== null;
+  }
+  /** The acknowledgment that turns "pending" back into nothing: the hub
+   *  broadcasts presence_update to the declaring identity too, so our own
+   *  username carrying our pending status means the declaration LANDED — and
+   *  re-asserting it on a later reconnect would stomp whatever a newer device
+   *  declares afterwards. A METHOD, not inline in the socket handler, so tests
+   *  drive the rule production runs instead of a copy of it — a test-local
+   *  re-implementation of this exact logic passed with the real clearing
+   *  deleted, which is how the previous round's test enshrined the bug. */
+  notePresenceAck(ev) {
+    if (ev?.event !== "presence_update" || ev.username !== this.identity?.username) return;
+    const frontier = this.selfStatusRev;
+    if (typeof ev.rev === "number" && ev.rev > this.selfStatusRev) this.selfStatusRev = ev.rev;
+    if (this.pendingPresence === null || ev.status !== this.pendingPresence) return;
+    if (typeof ev.rev !== "number" || ev.rev <= this.pendingBaselineRev || ev.rev < frontier) return;
+    this.pendingPresence = null;
+  }
   clientInfo;
   // handshake, re-sent on reconnect
   /** Is the hub socket usable RIGHT NOW?
@@ -60778,7 +60818,8 @@ var JefriClient = class _JefriClient {
       this.ws.on("open", () => {
         this.startPing();
         try {
-          this.ws.send(JSON.stringify({ type: "presence", status: this.lastPresence }));
+          if (this.pendingPresence !== null)
+            this.ws.send(JSON.stringify({ type: "presence", status: this.pendingPresence }));
           if (this.clientInfo)
             this.ws.send(JSON.stringify({ type: "client_info", ...this.clientInfo }));
         } catch {
@@ -60807,12 +60848,15 @@ var JefriClient = class _JefriClient {
         }
         if (ev.event === "registered") {
           this.identity = ev.identity;
+          const rev = ev.identity?.statusRev;
+          if (typeof rev === "number" && rev > this.selfStatusRev) this.selfStatusRev = rev;
           this.hasConnected = true;
           this.reconnectAttempts = 0;
         }
         if (ev.event === "error" && /auth/i.test(ev.message ?? "")) {
           this.authFailed = true;
         }
+        this.notePresenceAck(ev);
         this.emit(ev.event, ev);
         this.emit("*", ev);
       });
@@ -60901,7 +60945,8 @@ var JefriClient = class _JefriClient {
   }
   // --- actions -------------------------------------------------------------
   presence(status) {
-    this.lastPresence = status;
+    this.pendingPresence = status;
+    this.pendingBaselineRev = this.selfStatusRev;
     this.send({ type: "presence", status });
   }
   message(to, content3) {
@@ -63397,6 +63442,14 @@ app.post("/mcp", async (req, res) => {
     }
     return;
   }
+  if (draining && !sessionId && isInitializeRequest(req.body)) {
+    res.setHeader("retry-after", "1");
+    return res.status(503).json({
+      jsonrpc: "2.0",
+      error: { code: -32e3, message: "server is shutting down \u2014 retry; another instance will accept this session" },
+      id: null
+    });
+  }
   if (!sessionId && isInitializeRequest(req.body)) {
     if (initRateLimited(req)) {
       res.status(429).json({

package/dist/index.js

@@ -38648,8 +38648,48 @@ var JefriClient = class _JefriClient {
   // heartbeat: did we get a pong since the last ping?
   hasConnected = false;
   // armed for auto-reconnect only after the hub `registered` us
-  lastPresence = "online";
-  // re-announce this on reconnect
+  /** UNACKNOWLEDGED presence intent, or null. Set by presence(), cleared when
+   *  the hub's own presence_update for this identity confirms the declaration
+   *  landed. Null on reconnect means: send nothing and let the hub's persisted
+   *  answer stand.
+   *
+   *  Acknowledgment is the point, and it is what the first fix missed: a value
+   *  kept after delivery means "ever declared", not "pending" — so a client
+   *  that once declared away kept re-asserting it on every reconnect for the
+   *  life of the process, stomping whatever a newer device had chosen since.
+   *  The same stale-overwrite, one level down. */
+  pendingPresence = null;
+  /** The self statusRev BASELINE captured when the pending declaration was made.
+   *  An ack must be CAUSALLY newer than this — the audit reproduced a delayed
+   *  rev-9 event spending intent declared at a rev-10 baseline, after which the
+   *  server had already moved on. Identity + status matching alone cannot order
+   *  events; the revision can. */
+  pendingBaselineRev = 0;
+  /** Highest revision seen for our own status, from registered and from our own
+   *  presence_update events. */
+  selfStatusRev = 0;
+  /** Would a reconnect re-send a presence frame? True only while a declaration
+   *  is UNACKNOWLEDGED. Exposed for tests: the wire behaviour needs a live hub,
+   *  but the rule is checkable without one. */
+  wouldReassertPresence() {
+    return this.pendingPresence !== null;
+  }
+  /** The acknowledgment that turns "pending" back into nothing: the hub
+   *  broadcasts presence_update to the declaring identity too, so our own
+   *  username carrying our pending status means the declaration LANDED — and
+   *  re-asserting it on a later reconnect would stomp whatever a newer device
+   *  declares afterwards. A METHOD, not inline in the socket handler, so tests
+   *  drive the rule production runs instead of a copy of it — a test-local
+   *  re-implementation of this exact logic passed with the real clearing
+   *  deleted, which is how the previous round's test enshrined the bug. */
+  notePresenceAck(ev) {
+    if (ev?.event !== "presence_update" || ev.username !== this.identity?.username) return;
+    const frontier = this.selfStatusRev;
+    if (typeof ev.rev === "number" && ev.rev > this.selfStatusRev) this.selfStatusRev = ev.rev;
+    if (this.pendingPresence === null || ev.status !== this.pendingPresence) return;
+    if (typeof ev.rev !== "number" || ev.rev <= this.pendingBaselineRev || ev.rev < frontier) return;
+    this.pendingPresence = null;
+  }
   clientInfo;
   // handshake, re-sent on reconnect
   /** Is the hub socket usable RIGHT NOW?
@@ -38744,7 +38784,8 @@ var JefriClient = class _JefriClient {
       this.ws.on("open", () => {
         this.startPing();
         try {
-          this.ws.send(JSON.stringify({ type: "presence", status: this.lastPresence }));
+          if (this.pendingPresence !== null)
+            this.ws.send(JSON.stringify({ type: "presence", status: this.pendingPresence }));
           if (this.clientInfo)
             this.ws.send(JSON.stringify({ type: "client_info", ...this.clientInfo }));
         } catch {
@@ -38773,12 +38814,15 @@ var JefriClient = class _JefriClient {
         }
         if (ev.event === "registered") {
           this.identity = ev.identity;
+          const rev = ev.identity?.statusRev;
+          if (typeof rev === "number" && rev > this.selfStatusRev) this.selfStatusRev = rev;
           this.hasConnected = true;
           this.reconnectAttempts = 0;
         }
         if (ev.event === "error" && /auth/i.test(ev.message ?? "")) {
           this.authFailed = true;
         }
+        this.notePresenceAck(ev);
         this.emit(ev.event, ev);
         this.emit("*", ev);
       });
@@ -38867,7 +38911,8 @@ var JefriClient = class _JefriClient {
   }
   // --- actions -------------------------------------------------------------
   presence(status) {
-    this.lastPresence = status;
+    this.pendingPresence = status;
+    this.pendingBaselineRev = this.selfStatusRev;
     this.send({ type: "presence", status });
   }
   message(to, content3) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jefrichat-mcp",
-  "version": "0.48.8",
+  "version": "0.48.9",
   "description": "Jefri Chat connector — join the Jefri Chat network (WhatsApp for AI agents) from any MCP client (Claude, Codex, Cursor, …).",
   "type": "module",
   "bin": {