@rubytech/create-realagent-code 0.1.607 → 0.1.609

package/payload/platform/services/claude-session-manager/dist/http-server.js

@@ -60,6 +60,7 @@ import { computeMetering } from './session-metering.js';
 import { collectActivity } from './activity-rows.js';
 import { parseDayRange } from './activity-range.js';
 import { claudeStateRoot, projectSlugForCwd, jsonlPathForSessionId, sidecarPathForSessionId, permissionModeLogPathForSessionId, mcpDebugLogPathForSessionId, printStreamPathForSessionId, findExistingJsonlForSessionId, slugForExistingJsonl, jsonlPathForSlug, sidecarPathForSlug, projectsDirForCwd, detectRemoteControlSlug, classifyBindBlocker, classifyChildAuth, } from './jsonl-path.js';
+import { resolveRecoverAccount, formatRecoverAccountLine } from './recover-account.js';
 import { basename, dirname, join } from 'node:path';
 import { validateUserTitle } from './user-title-store.js';
 import { credentialsPathForConfigDir, snapshotAuthForFailureReason } from './auth-snapshot.js';
@@ -2995,7 +2996,38 @@ export function buildHttpApp(deps) {
             timed(deps.logger, 'POST', '/rc-spawn', 400, Date.now() - start);
             return c.json({ error: 'targetAccountId not in this install registry' }, 400);
         }
-        const effectiveAccountId = requestedAccountId ?? deps.accountId;
+        // Task 2728 — a `recover: true` request carries no `targetAccountId`: the
+        // recovery caller's body literal (`managerRcRecover`) has no such field, and
+        // its docstring records that omitting it lets the manager default apply. The
+        // default below then handed every wedged SUB-ACCOUNT session to the boot
+        // house account — same conversation id, second account's projects dir, and
+        // nothing logged. It is the same silent-default hazard the reject above
+        // names for an UNKNOWN account, arriving through the ABSENT case instead.
+        //
+        // The account of record is the one whose directory holds this session's
+        // sidecar. Resolving it here, above `effectiveAccountDir`, means the wedge
+        // classifier reads the transcript's freshness from the session's own account
+        // rather than from a house directory that never held it, so the kill decision
+        // and the respawn key off one account.
+        //
+        // Unchanged: every non-recover caller keeps `?? deps.accountId`, and a
+        // recover that names an account explicitly still gets that account.
+        const recoverResolution = recover && sessionId !== null && requestedAccountId === undefined
+            ? resolveRecoverAccount({ accountsRoot, sessionId })
+            : null;
+        const effectiveAccountId = recoverResolution?.outcome === 'ok' ? recoverResolution.accountId : (requestedAccountId ?? deps.accountId);
+        // The line and the refusal both live in the recover branch below, AFTER the
+        // not-live guard: a recover against a session this manager holds no PTY for
+        // is the cold-start class (Tasks 782/813), which that guard reports as a
+        // benign 200 no-op by design. Refusing it here instead would turn every
+        // cold-start sweep into an error the gateway logs as a failure.
+        const recoverAccountLine = () => formatRecoverAccountLine({
+            sessionId,
+            resolved: recoverResolution?.outcome === 'refused-no-sidecar' ? null : effectiveAccountId,
+            source: recoverResolution ? 'sidecar' : requestedAccountId !== undefined ? 'body' : 'default',
+            outcome: recoverResolution?.outcome === 'refused-no-sidecar' ? 'refused-no-sidecar' : 'ok',
+            candidates: recoverResolution?.candidates ?? 0,
+        });
         // Task 1315 — the per-request resolved account's directory. Every
         // filesystem lookup and the PTY launch itself must key off this, not
         // the boot-time spawn cwd fixed to the house account for the manager's
@@ -3075,6 +3107,16 @@ export function buildHttpApp(deps) {
                     timed(deps.logger, 'POST', '/rc-spawn', 200, Date.now() - start);
                     return c.json({ live: false, sessionId, recovered: false }, 200);
                 }
+                // Task 2728 — the recovery is real from here: a live child this manager
+                // owns. Name the account it resolved to before anything acts on it.
+                deps.logger(recoverAccountLine());
+                // No account holds a record of this session, so there is nothing to
+                // recover under any account and the house account is never the right
+                // answer. Refuse before the classifier can kill the child.
+                if (recoverResolution?.outcome === 'refused-no-sidecar') {
+                    timed(deps.logger, 'POST', '/rc-spawn', 400, Date.now() - start);
+                    return c.json({ error: 'recover: no sidecar record for this sessionId' }, 400);
+                }
                 const liveRow = deps.watcher.getBySessionId(sessionId);
                 const jp = jsonlPathForSessionId(effectiveAccountDir, sessionId);
                 let jsonlMtimeMs = null;
@@ -3974,7 +4016,11 @@ export function buildHttpApp(deps) {
         // grep on one sessionId shows where the spawn landed. requested==resolved
         // (or default=true when none requested) is success; the reject path above
         // logs op=account-reject and never reaches here.
-        deps.logger(`[spawn] op=account-resolved sessionId=${sessionId ? sessionId.slice(0, 8) : 'new'} requested=${requestedAccountId ?? ''} resolved=${effectiveAccountId} dir=${env.ACCOUNT_DIR} default=${requestedAccountId === undefined}`);
+        // Task 2728 — `default` means the boot-account fallback was APPLIED, which is
+        // no longer the same as "the body named no account": a recover that named
+        // none is resolved from its sidecar instead. Reporting that spawn as
+        // default=true would say the house account was used when it was not.
+        deps.logger(`[spawn] op=account-resolved sessionId=${sessionId ? sessionId.slice(0, 8) : 'new'} requested=${requestedAccountId ?? ''} resolved=${effectiveAccountId} dir=${env.ACCOUNT_DIR} default=${requestedAccountId === undefined && recoverResolution === null}`);
         // Task 606 — standing startup signal: confirms per-spawn whether the
         // child env carries a session id. `mode=new` when none was requested
         // (CLI fresh-spawn), else the resolved fresh/resume.
@@ -4582,6 +4628,43 @@ export function buildHttpApp(deps) {
         // `pid-bind-timeout` sent every reader to the wrong mechanism. Nor does
         // `spawn-not-ready` claim an exit — a blocked-but-alive child never exits.
         const reason = outcome === 'bound' ? null : outcome === 'unbound' ? 'bridge-unregistered' : 'spawn-not-ready';
+        // Task 2729 — the status the caller branches on. Until this task every
+        // spawn answered 200, so no caller could separate a working spawn from one
+        // whose child never bound: the 2026-08-15 laptop spawn halted on the
+        // folder-trust dialog, answered 200, and the admin shell then polled
+        // /<id>/meta for a session that did not exist.
+        //
+        // Three conditions, all of them required, because each rules out a
+        // different way the spawn could in fact have worked:
+        //   bridgeSessionId === null  — no slug on either bind signal.
+        //   !pidFileSeen              — `waitForPid` did not resolve.
+        //   servingRow === undefined  — and the watcher has no row for this pid
+        //                               from ANY source, pid file or jsonl.
+        //
+        // The third is not implied by the second. `pidFileSeen` is decided by
+        // `deps.pidFileTimeoutMs`, a SHORTER bound than the bind wait (device
+        // evidence 2026-08-15: `op=wait-pid-failed … ms=30000` inside a 60 s
+        // wait), so it can be a stale `false` by the time the verdict is taken.
+        // A child that registered in that gap is the Task 1716 shape — live,
+        // serving, simply not navigable — and must keep its 200. Reading only the
+        // first two conditions would answer a hard failure for a healthy session,
+        // which is the 1716 false verdict with the sign flipped.
+        //
+        // A child that DID write a pid file and then died stays 200 as well: it
+        // became a registered session and then ended, which is a different event
+        // from a spawn that produced nothing at all.
+        //
+        // `getByPid` resolves through `sessionIdByPid`, which a pid-file delete
+        // unindexes. A pid file that outlived its process AND whose pid the OS then
+        // recycled onto this child would read as a serving row that is not ours.
+        // That miss fails toward the pre-2729 answer — it can suppress a 503, never
+        // manufacture one — so it costs a missed report, not a false failure.
+        const servingRow = deps.watcher.getByPid(pty.pid);
+        const bindFailed = bridgeSessionId === null && !pidFileSeen && servingRow === undefined;
+        const status = bindFailed ? 503 : 200;
+        // Classified once, so the three places that report it — op=bind-signal-absent,
+        // op=bind-outcome, and the response body — can never disagree.
+        const blocker = bridgeSessionId ? 'none' : classifyBindBlocker(bindBuf);
         // Task 1406 — derive the child's first-turn auth verdict. A bound child
         // authenticated; an unbound child that printed `Not logged in` is the
         // file-healthy-but-child-unauthenticated signature this task closes. Emitted
@@ -4609,10 +4692,25 @@ export function buildHttpApp(deps) {
             // stdout tail; in a failed bind no slug was found so it was never released
             // and carries the (sub-8 KB) blocking screen — e.g. the CC >= 2.1.167
             // "Settings Warning" the redundant allow:["*"] used to trigger.
-            deps.logger(`[rc-spawn] op=bind-signal-absent unitToken=${unitToken} pid=${pty.pid} expected=stdout-url cliVersion=${detectCliVersion(deps.claudeBin)} stdoutBytes=${stdoutBytes} pidFileSeen=${pidFileSeen} blocker=${classifyBindBlocker(bindBuf)}`);
+            deps.logger(`[rc-spawn] op=bind-signal-absent unitToken=${unitToken} pid=${pty.pid} expected=stdout-url cliVersion=${detectCliVersion(deps.claudeBin)} stdoutBytes=${stdoutBytes} pidFileSeen=${pidFileSeen} blocker=${blocker}`);
             deps.logger(`[rc-spawn] op=resume-timeout sessionId=${sessionId ?? 'none'} waitedMs=${RC_SPAWN_URL_WAIT_MS} slug=none`);
         }
         deps.logger(`[rc-spawn] op=resume-response sessionId=${sessionId ?? 'none'} slug=${bridgeSessionId ?? 'none'} outcome=${outcome} reason=${reason ?? 'none'}`);
+        // Task 2729 — the verdict and the answer on ONE line. Both halves were
+        // already logged before this task, on two lines nothing reconciled: an
+        // `op=bind-signal-absent` and, on the same millisecond, an `outcome=200`.
+        // Reading them apart is what let a failed spawn look like a working one.
+        //
+        // `serving=` is the field this line adds beyond the two the task named. It
+        // is the third condition, and without it the rule is not checkable from one
+        // line: `bound=false pidFileSeen=false status=200` is a healthy Task 1716
+        // session, not a defect, and only `serving=true` says which it was.
+        //
+        // Standing signal: a non-2xx `status` appears exactly when all three of
+        // `bound=false pidFileSeen=false serving=false` hold. Any other pairing —
+        // a 2xx on all three false, or a non-2xx with any of them true — is this
+        // defect, or its inverse, recurring.
+        deps.logger(`[rc-spawn] op=bind-outcome unitToken=${unitToken} bound=${bridgeSessionId !== null} pidFileSeen=${pidFileSeen} serving=${servingRow !== undefined} status=${status} blocker=${blocker}`);
         // Every rc-spawn child runs inside a `systemd-run --user --scope`
         // unit driven by node-pty; the operator-visible spawnMethod marker
         // is kept stable so server.log greps survive the Task 573 cleanup.
@@ -4653,7 +4751,30 @@ export function buildHttpApp(deps) {
             writeReseatMarker(sessionsDir, forkFromSessionId, sessionId, Date.now(), deps.logger);
             deps.logger(`[webchat:reseat] op=reseat-retire from=${forkFromSessionId} fork=${sessionId} outcome=marked`);
         }
-        timed(deps.logger, 'POST', '/rc-spawn', 200, Date.now() - start);
+        timed(deps.logger, 'POST', '/rc-spawn', status, Date.now() - start);
+        // Task 2729 — the spawn produced nothing a caller can use. `503` with
+        // `{error:'spawn-failed', reason}` is the shape this door already returns
+        // for its pre-spawn refusals, and both clients (`managerRcSpawn`,
+        // `managerRcRecover`) already branch on a non-2xx, as does the admin proxy
+        // (`session-rc-spawn.ts`, which forwards the status and this body).
+        //
+        // The body carries the bind outcome alongside the status, and keeps every
+        // field a 200 carried, so a caller reading the failure still knows which
+        // child and which session it was, and `blocker` names the screen that
+        // stopped it. `bridgeSessionId` and `slug` are null here by construction.
+        if (bindFailed) {
+            return c.json({
+                error: 'spawn-failed',
+                reason,
+                outcome,
+                blocker,
+                spawnedPid: pty.pid,
+                sessionId: sessionId ?? null,
+                bridgeSessionId,
+                slug: bridgeSessionId,
+                ...(recoverOutcome ? { live: true, classification: recoverOutcome.classification, recovered: false } : {}),
+            }, 503);
+        }
         // `slug` is the Task 648 canonical field the client navigates by;
         // `bridgeSessionId` is the same value, retained so pre-648 consumers and
         // tests keep resolving. They never diverge — `slug` IS `bridgeSessionId`.