You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to #343, which merged as b7c68462. Raised by codex on that PR and verified before filing; deliberately not held against the outage fix because the cloud container never runs loop.
isReadOnlyFactoryCommand classifies loop --dry-run as read-only, so it gets a RelayFleetClient that refuses to mint an identity. But runLoop() still performs live recovery on every iteration regardless of dryRun:
factory.ts:4249runLoop()
:4268 and :4273 → #drainReadyClarificationWake() — can resume or spawn an agent when durable state holds a replied clarification
:4274 → #sweepPrStateCompletions('run-loop') — can release agents when an in-flight PR completed
With only a workspace key configured, those now throw ReadOnlyFleetIdentityError and the loop reports a failure instead of completing the recovery.
runOnce does not share this: #runOnceWithDiscoveryFence gates at if (!(opts.dryRun ?? this.#config.dryRun)), so the dry-run path never reaches the recovery calls. That asymmetry between runOnce and runLoop is the actual defect worth fixing.
Two dispositions, pick with reasoning rather than defaulting:
Drop loop from the read-only set until (1) lands — narrower and safer, but leaves a command that mints an identity purely to observe.
Prefer (1). If you take (2), say so on this issue so nobody reads the classification as settled.
Either way this needs a must-fire/must-not-fire pair: a loop --dry-run over durable state containing a replied clarification, asserting the recovery either completes or is skipped, and a control proving the test would notice the opposite.
Not urgent and not a dispatch blocker — no container path invokes loop (container/entrypoint.mjs runs only status at :1028 and run-once --dry-run at :1049).
Follow-up to #343, which merged as
b7c68462. Raised by codex on that PR and verified before filing; deliberately not held against the outage fix because the cloud container never runsloop.isReadOnlyFactoryCommandclassifiesloop --dry-runas read-only, so it gets aRelayFleetClientthat refuses to mint an identity. ButrunLoop()still performs live recovery on every iteration regardless ofdryRun:factory.ts:4249runLoop():4268and:4273→#drainReadyClarificationWake()— can resume or spawn an agent when durable state holds a replied clarification:4274→#sweepPrStateCompletions('run-loop')— can release agents when an in-flight PR completedWith only a workspace key configured, those now throw
ReadOnlyFleetIdentityErrorand the loop reports a failure instead of completing the recovery.runOncedoes not share this:#runOnceWithDiscoveryFencegates atif (!(opts.dryRun ?? this.#config.dryRun)), so the dry-run path never reaches the recovery calls. That asymmetry betweenrunOnceandrunLoopis the actual defect worth fixing.Two dispositions, pick with reasoning rather than defaulting:
dryRun— the more correct fix, since a dry run that resumes agents is not a dry run, and the current behaviour is arguably a pre-existing bug that fix(cli): stop read-only commands registering a relay agent (factory-cloud#55) #343 merely made visible.loopfrom the read-only set until (1) lands — narrower and safer, but leaves a command that mints an identity purely to observe.Prefer (1). If you take (2), say so on this issue so nobody reads the classification as settled.
Either way this needs a must-fire/must-not-fire pair: a
loop --dry-runover durable state containing a replied clarification, asserting the recovery either completes or is skipped, and a control proving the test would notice the opposite.Not urgent and not a dispatch blocker — no container path invokes
loop(container/entrypoint.mjsruns onlystatusat:1028andrun-once --dry-runat:1049).