@inetafrica/open-claudia 3.0.31 → 3.0.34

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Changelog
 
+## v3.0.34 — /upgrade no longer triggers a rollout storm
+
+- **One `/upgrade` used to mean up to five rollouts.** On AgentSpace pods the control plane answers `/upgrade` by rolling the deployment, which SIGTERMs the bot mid-turn. Telegram long-polling keeps no persisted offset, so the still-unconfirmed `/upgrade` update was redelivered to the freshly booted pod — which triggered *another* rollout, and so on. Observed on rahilcoder 2026-07-17: deployment revisions 47–51 (five rollouts in three minutes) from a single command; every earlier `/upgrade` had silently double-fired the same way (revs 42/43, 45/46).
+- **Fix: an upgrade-in-flight marker (`upgrade-in-flight.json` in the config dir, 10-minute freshness) guards the handler.** A redelivered or impatiently re-run `/upgrade` inside the window is acknowledged but not re-triggered: if the pod has already restarted since the request it replies "that upgrade already went through", otherwise "already in flight". The marker is cleared on a definitive trigger failure so an immediate retry stays possible, and simply ages out otherwise.
+- **The ack now goes out BEFORE the rollout is requested.** Previously the "Upgrade requested" confirmation was sent after the control-plane call, so the SIGTERM routinely killed it — Rahil saw reboot greetings *before* any acknowledgement. Ack-first means the user always sees the confirmation, then the reboot.
+- **Agent-space / OpenClaw:** no new deps, no new env, no schema change; Docker image builds FROM the existing `:base`. Existing pods pick this up on their next upgrade — that upgrade itself will still multi-fire (old code is doing the triggering), all later ones are single-shot.
+
+## v3.0.33 — Full sudo inside the pod (re-cut of v3.0.32; the pin guard bit us again)
+
+- **`claudia` now has `NOPASSWD:ALL` sudo in the pod image.** The rebuilt `:base` widens the baked sudoers from the old command allow-list to full passwordless sudo, so the agent can install packages and operate inside its own container like a normal machine. This pairs with agent-space's IaaS-style security-policy system: the blast radius is fenced at the pod's NetworkPolicy (egress/ingress presets, DB-rendered), not by crippling the user inside the container.
+- **Re-cut of v3.0.32.** That tag bumped `package.json` but not the version pin in `test-provider-language.js`, so `pretest` asserted 3.0.31, the **build** job failed, and the **docker** job was skipped — nothing published, `:latest` stayed on 3.0.31. Identical payload here with the pin bumped. (Same failure mode as v3.0.30 → v3.0.31.)
+- **Agent-space / OpenClaw:** no new deps, no new env, no schema change; Docker image builds FROM the rebuilt full-sudo `:base`. Existing pods pick this up on their next approved upgrade.
+
 ## v3.0.31 — Re-cut of the approval-card release (the version-pin guard bit us)
 
 - **Same feature payload as v3.0.30, this time it builds.** The v3.0.30 tag's build failed before publishing anything. `test-provider-language.js` pins the release version and asserts it "must remain unchanged without explicit approval" — a deliberate gate so every bump is consciously acknowledged in the same commit. `package.json` was bumped to 3.0.30 but that pin wasn't, so `pretest` asserted 3.0.29, the **build** job failed, and the **docker** job was skipped (no npm publish, no image — `:base` never entered it). The pin now tracks the release, so the build goes green.

package/core/handlers.js

@@ -29,6 +29,7 @@ const keyring = require("./keyring");
 const { redactSensitive, registerSecrets } = require("./redact");
 const { runDoctorChecks, formatDoctorReport } = require("./doctor");
 const { isNewerVersion } = require("./version");
+const { recordUpgradeRequested, upgradeInFlightSince, clearUpgradeMarker } = require("./upgrade-marker");
 const jobs = require("./jobs");
 const scheduler = require("./scheduler");
 const skillsLib = require("./skills");
@@ -672,23 +673,45 @@ register({
     // delegate to the control plane so the deployment can be rolled with a
     // fresh image pull. The local npm path can't do that.
     if (process.env.AGENTSPACE_POD_TOKEN && process.env.AGENTSPACE_API_URL) {
+      // Redelivery guard: the rollout SIGTERMs this pod mid-turn and Telegram
+      // redelivers the still-unconfirmed /upgrade update to the rebooted pod.
+      // Unguarded, each replay triggered another rollout (one /upgrade was
+      // observed to cause five). A fresh marker means the request was already
+      // honoured — by this boot or the previous one.
+      const since = upgradeInFlightSince();
+      if (since) {
+        const bootedAt = Date.now() - Math.round(process.uptime() * 1000);
+        if (since < bootedAt) {
+          await send(`That upgrade already went through — I restarted onto the freshly pulled image and I'm running v${CURRENT_VERSION}. Skipping the duplicate trigger.`);
+        } else {
+          const mins = Math.max(1, Math.round((Date.now() - since) / 60000));
+          await send(`An upgrade rollout is already in flight (requested ~${mins} min ago) — not triggering another. If I seem stuck, the guard clears 10 minutes after the request.`);
+        }
+        return;
+      }
+      // Ack BEFORE triggering: once the control plane rolls the deployment we
+      // can be SIGTERM'd at any moment, and an unsent ack dies with us.
+      await send("Upgrade requested — AgentSpace will pull latest image and restart, see you in a minute.");
+      recordUpgradeRequested();
       try {
         const result = await requestAgentSpaceUpgrade();
         if (result && (result.status === 202 || result.status === 200)) {
-          await send("Upgrade requested — AgentSpace will pull latest image and restart, see you in a minute.");
           return;
         }
         // A client-side timeout is not a failure: the control plane triggers the
         // rollout fire-and-forget, and a pod being rolled is exactly when its own
         // in-flight request gets cut off. Framing it as "failed" invites a retry
-        // storm of redundant rollouts, so surface it as pending instead.
+        // storm of redundant rollouts, so surface it as pending instead — and
+        // keep the marker, since the rollout is most likely underway.
         if (result && result.status === 0 && /timeout/i.test(result.body || "")) {
           await send("Upgrade request sent but the reply timed out — likely because I'm already restarting. Give it a minute before re-running; I should come back on the new image.");
           return;
         }
+        clearUpgradeMarker();
         await send(`Upgrade request failed (status ${result?.status || "?"}). ${(result?.body || "").slice(0, 300)}`);
         return;
       } catch (e) {
+        clearUpgradeMarker();
         await send(`Upgrade request error: ${e.message || e}`);
         return;
       }

package/core/upgrade-marker.js

@@ -0,0 +1,42 @@
+// Guards /upgrade on AgentSpace-managed pods against the redelivery loop:
+// the control-plane rollout SIGTERMs this pod mid-turn, Telegram long-polling
+// keeps no persisted offset, so the still-unconfirmed /upgrade update is
+// redelivered to the freshly booted pod — which would trigger ANOTHER rollout
+// (observed: one /upgrade → five rollouts in three minutes). A fresh marker
+// on disk tells the handler the request was already honoured.
+
+const fs = require("fs");
+const path = require("path");
+const { CONFIG_DIR } = require("./config");
+
+const FILE = path.join(CONFIG_DIR, "upgrade-in-flight.json");
+// An image pull + pod recreate completes well inside this window; after it a
+// re-run of /upgrade is treated as a genuine new request.
+const FRESH_MS = 10 * 60 * 1000;
+
+// Call right before triggering the rollout. Best-effort: never throws.
+function recordUpgradeRequested() {
+  try {
+    fs.writeFileSync(FILE, JSON.stringify({ at: Date.now() }));
+  } catch (e) { /* the recorder must never itself throw */ }
+}
+
+// Epoch ms of the in-flight upgrade request, or null when none is fresh.
+// Deliberately does NOT clear the file: Telegram may redeliver more than one
+// unconfirmed copy of the command, so the guard must hold until it ages out.
+function upgradeInFlightSince() {
+  try {
+    const rec = JSON.parse(fs.readFileSync(FILE, "utf8"));
+    if (rec && typeof rec.at === "number" && Date.now() - rec.at <= FRESH_MS) {
+      return rec.at;
+    }
+  } catch (e) { /* absent/unreadable ⇒ no upgrade in flight */ }
+  return null;
+}
+
+// Call when the trigger definitively failed, so an immediate retry is allowed.
+function clearUpgradeMarker() {
+  try { fs.unlinkSync(FILE); } catch (e) {}
+}
+
+module.exports = { recordUpgradeRequested, upgradeInFlightSince, clearUpgradeMarker };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@inetafrica/open-claudia",
-  "version": "3.0.31",
+  "version": "3.0.34",
   "description": "An always-on, provider-agnostic coding-agent harness for Claude Code and OpenAI Codex via chat",
   "main": "bot.js",
   "bin": {

package/test-provider-language.js

@@ -32,20 +32,15 @@ assert.doesNotMatch(setup, /Your Claude Code bot is connected|Description=Claude
 
 const pkg = JSON.parse(read("package.json"));
 assert.match(pkg.description, /provider-agnostic coding-agent harness/i);
-// 3.0.31 approved by Sumeet 2026-07-16 ("push out a new version"): re-cuts the
-// v3.0.30 approval-card UX after that tag's build tripped THIS guard — the pin
-// below wasn't bumped alongside package.json, so pretest asserted 3.0.29 and the
-// build failed (docker skipped, nothing published). The UX rework: the owner's
-// approval card now shows "From <name>: <ask>" plus the proposed reply/action
-// (inbound text + speaker name threaded through context -> escalate -> approval
-// record). Approve/Deny edits the card in place (fresh-message fallback when the
-// adapter can't edit). "Make a rule" approves + delivers, then asks "just <name>
-// or everyone?" -> saved to the per-person mandate or a new owner-editable global
-// guardrails store (external-guardrails.md, /guardrails command). The enforcer
-// now vets every external reply against three layers: hardcoded security floor /
-// global guardrails / per-person mandate. No autonomy change: default-deny
-// stands, the guard still fails closed, and only the owner can create rules.
-assert.strictEqual(pkg.version, "3.0.31", "release version must remain unchanged without explicit approval");
+// 3.0.34 approved by Sumeet 2026-07-17 (Rahil's triple-reboot screenshot +
+// "explain and fix"): /upgrade redelivery guard. On AgentSpace pods the
+// rollout SIGTERMs the bot mid-turn, Telegram long-polling holds no persisted
+// offset, and the unconfirmed /upgrade update is redelivered to the rebooted
+// pod — each replay triggered ANOTHER rollout (one /upgrade → five rollouts,
+// deployment revisions 47-51). Fix: upgrade-in-flight marker in CONFIG_DIR
+// guards the handler, and the ack is sent BEFORE the trigger so it can't be
+// lost to the SIGTERM.
+assert.strictEqual(pkg.version, "3.0.34", "release version must remain unchanged without explicit approval");
 for (const keyword of ["claude", "codex", "coding-agent", "provider-agnostic"]) {
   assert.ok(pkg.keywords.includes(keyword), `package keyword missing: ${keyword}`);
 }