npm - agent-dag - Versions diffs - 1.36.0 → 1.36.2 - Mend

agent-dag 1.36.0 → 1.36.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (4) hide show

package/dist/web/assets/{index-OvdPf_n3.js → index-DMZuxcfY.js} +2 -2
package/dist/web/index.html +1 -1
package/package.json +1 -1
package/src/server/system-metrics.mjs +130 -26

package/dist/web/index.html CHANGED Viewed

@@ -40,7 +40,7 @@
         document.documentElement.setAttribute("data-theme", stored === "light" ? "light" : "dark");
       })();
     </script>
-    <script type="module" crossorigin src="/assets/index-OvdPf_n3.js"></script>
+    <script type="module" crossorigin src="/assets/index-DMZuxcfY.js"></script>
     <link rel="stylesheet" crossorigin href="/assets/index-CaAP5Ufx.css">
   </head>
   <body>

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "agent-dag",
-  "version": "1.36.0",
+  "version": "1.36.2",
   "description": "Live deck of Claude Code and Codex agents — watch tool calls, token spend and every Claude Code subagent on one calm canvas. Also available as npx ccdeck and npx agent-dag.",
   "type": "module",
   "bin": {

package/src/server/system-metrics.mjs CHANGED Viewed

@@ -268,11 +268,53 @@ async function readSwap(platform = process.platform) {
 const TOP_N = 8;
 /**
- * Rows out of `ps -Aceo pid,pcpu,pmem,comm -r`.
+ * The `ps` argument list, which is not the same list on both Unixes.
  *
- * `-c` gives the executable name without its full path and without the argv
- * that would leak a prompt or a token into the UI; `-r` sorts by current CPU,
- * which is the ordering that answers "what is eating this machine right now".
+ * `-r` was shipped for both and means two different things. On BSD it sorts the
+ * output by current CPU, which is the ordering the panel is built around. On
+ * Linux procps it is *"restrict the selection to only running processes"* — a
+ * filter on state `R`, applied in PID order. A Linux deck therefore listed
+ * whatever happened to be on a CPU at the instant of the sample: usually one or
+ * two rows on an idle machine, and never the busiest ones, since a process
+ * pinning a core while blocked on I/O sits in `D` and one merely burning CPU
+ * over time is normally caught in `S`. Nothing errored and nothing was empty,
+ * which is why it survived two releases (#492).
+ *
+ * `--sort=-pcpu` is procps' own way to say what `-r` says on BSD. The column
+ * order is deliberately identical on both so one parser reads both, and `comm`
+ * stays last so a name containing a space survives intact.
+ *
+ * Keyed on linux rather than on darwin, because linux is the platform that is
+ * wrong: `-r` sorts on every BSD, while `--sort` is a procps long option that
+ * would make FreeBSD and OpenBSD exit non-zero. This way the only branch that
+ * changes is the one that was broken.
+ *
+ * Pure and exported for the same reason the parsers are: the command
+ * construction is the part that differs per platform, and a fixture cannot
+ * prove which flags were passed to produce it.
+ */
+export function psArgs(platform = process.platform) {
+  // procps: an explicit CPU sort, and `comm` in `-o` is what keeps argv — and
+  // any prompt or token on it — out of the panel. Linux `comm` comes from
+  // /proc/<pid>/comm and is capped at 15 characters.
+  if (platform === "linux") return ["-eo", "pid,pcpu,pmem,comm", "--sort=-pcpu"];
+  // BSD/macOS: `-c` prints the accounting name rather than the argument vector,
+  // and `-r` sorts by current CPU.
+  return ["-Aceo", "pid,pcpu,pmem,comm", "-r"];
+}
+/**
+ * Rows out of `ps -o pid,pcpu,pmem,comm`, in that column order on both Unixes —
+ * see psArgs for how each platform is asked for it.
+ *
+ * `pcpu` is a percentage of ONE core on both, so a multi-threaded process runs
+ * past 100 and that is information rather than an error: 157 is one and a half
+ * cores. cpuFromDeltas puts the Windows column on this same scale.
+ *
+ * There is no row limit in the query because neither `ps` has one and `run`
+ * deliberately never inherits a shell, so there is no `| head` to pipe into.
+ * The loop below stops at `limit` instead, which costs one parse of a string
+ * we have already paid to read.
  */
 export function parsePsProcesses(text, limit = TOP_N) {
   const lines = String(text ?? "").trim().split("\n");
@@ -287,50 +329,110 @@ export function parsePsProcesses(text, limit = TOP_N) {
 }
 /**
- * Rows out of the Windows performance counter.
+ * Rows out of `Get-Process`.
  *
- * `Get-Process` is the obvious call and the wrong one: its `CPU` property is
- * total processor SECONDS consumed since the process started, so sorting by it
- * ranks whatever has been running longest rather than whatever is busy now — a
- * different question, and not the one the panel asks. The formatted performance
- * counter publishes `PercentProcessorTime` directly, already a rate, so one
- * query gives the same thing `ps -r` gives on Unix without a second sample.
+ * NOT `Win32_PerfFormattedData_PerfProc_Process`, which is what this used and
+ * which is not a class you may assume exists. It is published by perflib, and
+ * perflib is deregistered often enough to matter — a corporate image, a bad
+ * in-place upgrade, a half-run `lodctr`. On a machine reported from the field
+ * the class was simply absent (`Get-CimInstance: Invalid class`), and `typeperf`
+ * failed identically, which places the fault below WMI rather than in it. WMI
+ * was only mirroring what perflib had stopped publishing.
  *
- * `_Total` and `Idle` are pseudo-processes in that class and are dropped.
+ * `Get-Process` reads through NtQuerySystemInformation instead, so it depends on
+ * nothing that can be unregistered. The cost is that its `CPU` is total
+ * processor SECONDS since the process started, not a rate — so a percentage has
+ * to be derived from two readings, exactly the way the machine-wide figure is
+ * already derived from two tick samples. Reliability is worth one extra poll:
+ * an instant number from a class that may not exist is worth nothing at all.
  */
-export function parseWindowsProcesses(json, totalMem, limit = TOP_N) {
+export function parseGetProcessJson(json, totalMem) {
   let rows;
   try { rows = typeof json === "string" ? JSON.parse(json) : json; }
   catch { return []; }
   if (!rows) return [];
   if (!Array.isArray(rows)) rows = [rows];
-  const cores = os.cpus().length || 1;
   return rows
-    .filter(r => r && r.Name && r.Name !== "_Total" && r.Name !== "Idle")
+    .filter(r => r && r.ProcessName)
     .map(r => ({
-      pid: Number(r.IDProcess) || 0,
-      // The counter is per-core-summed, exactly like macOS's 0-to-N00 scale, so
-      // it is normalised here to the 0-100 the Unix branch already reports.
-      cpu: Math.round((Number(r.PercentProcessorTime) || 0) / cores * 10) / 10,
+      pid: Number(r.Id) || 0,
+      name: String(r.ProcessName),
+      // Null rather than 0 when the process denies the read: a system process
+      // we cannot query has an unknown CPU time, and calling that zero would
+      // rank it as idle.
+      cpuSec: typeof r.CPU === "number" ? r.CPU : null,
       mem: totalMem > 0
         ? Math.round((Number(r.WorkingSetPrivate) || 0) / totalMem * 1000) / 10
         : 0,
-      name: String(r.Name),
-    }))
-    .sort((a, b) => b.cpu - a.cpu)
-    .slice(0, limit);
+    }));
+}
+/**
+ * Turn two `Get-Process` readings into a percentage per process.
+ *
+ * `prev` maps pid to the cpuSec of the previous reading. A pid absent from it —
+ * a process that started since — has no delta and reports null rather than a
+ * number invented from its whole lifetime, which would rank a freshly spawned
+ * compiler as though it had been burning a core since boot.
+ *
+ * Per core, NOT per machine, because that is what the column beside it means:
+ * `ps -o pcpu` is a percentage of one core on both Unixes and is reported
+ * unmodified, so a row reading 157 there is a process using one and a half
+ * cores. This used to divide by the core count and clamp to 100 on the reasoning
+ * that Unix reported 0-100 — it does not, and never did, so the normalisation
+ * corrected a scale that already matched and introduced the mismatch it was
+ * written to prevent: on a 12-core machine six busy cores read 600 on macOS and
+ * 50 on Windows (#493). One CPU-second burned per wall-second is 100 here, on
+ * every platform.
+ *
+ * Core count is deliberately not a parameter any more. The aggregate meter's
+ * 0-100 convention (see cpuPercent) is a different question with a different
+ * answer, and the only way this drifts back is if a core count is in reach.
+ */
+export function cpuFromDeltas(rows, prev, elapsedMs, limit = TOP_N) {
+  const secs = elapsedMs / 1000;
+  const out = rows.map(r => {
+    const before = prev instanceof Map ? prev.get(r.pid) : undefined;
+    let cpu = null;
+    if (r.cpuSec != null && before != null && secs > 0) {
+      const d = r.cpuSec - before;
+      // A counter that went backwards means the pid was reused by a different
+      // process; report nothing rather than a negative or a wild number.
+      if (d >= 0) cpu = Math.round((d / secs) * 1000) / 10;
+    }
+    return { pid: r.pid, cpu, mem: r.mem, name: r.name };
+  });
+  // Until the second reading lands there is no CPU to sort on, so the list is
+  // ordered by memory — which is a real answer to "what is this machine doing",
+  // not a placeholder.
+  const haveCpu = out.some(r => r.cpu != null);
+  out.sort(haveCpu
+    ? (a, b) => (b.cpu ?? -1) - (a.cpu ?? -1)
+    : (a, b) => b.mem - a.mem);
+  return out.slice(0, limit);
 }
 /** The process list, on demand only — never on the ambient timer. */
+/** Previous Windows reading, so the next one can be a rate. Cleared with the
+ *  rest of the sampler state. */
+let prevProcCpu = null;
+let prevProcAt = 0;
 export async function readProcesses(platform = process.platform) {
   if (platform === "win32") {
     const out = await run("powershell.exe", [
       "-NoProfile", "-NonInteractive", "-Command",
-      "Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | Select-Object Name,IDProcess,PercentProcessorTime,WorkingSetPrivate | ConvertTo-Json -Compress",
+      "Get-Process | Select-Object Id,ProcessName,CPU,@{n='WorkingSetPrivate';e={$_.PrivateMemorySize64}} | ConvertTo-Json -Compress",
     ], 6_000);
-    return out ? parseWindowsProcesses(out.trim(), os.totalmem()) : [];
+    if (!out) return [];
+    const rows = parseGetProcessJson(out.trim(), os.totalmem());
+    const now = Date.now();
+    const result = cpuFromDeltas(rows, prevProcCpu, now - prevProcAt);
+    prevProcCpu = new Map(rows.filter(r => r.cpuSec != null).map(r => [r.pid, r.cpuSec]));
+    prevProcAt = now;
+    return result;
   }
-  const out = await run("ps", ["-Aceo", "pid,pcpu,pmem,comm", "-r"], 4_000);
+  const out = await run("ps", psArgs(platform), 4_000);
   return out ? parsePsProcesses(out) : [];
 }
@@ -386,6 +488,8 @@ export function stopSystemMetrics() {
   memory = null;
   cores = null;
   swap = null;
+  prevProcCpu = null;
+  prevProcAt = 0;
 }
 /**