[freeqaz]

Problem

#2990 labels a deploying version "Deploying". Two read failures still leave that label disagreeing with the deployment record (finding 2085):

• Agent reread fails after a completed deployment. The notice skips a success and waits for the Agent reread to make the version current. When that reread fails, nothing re-renders, so the page shows "Deploying version · … It becomes the current version only if its deployment completes." beside "v2 · Completed", indefinitely.
• One status read fails mid-deploy. One failed deployment status read while v2 is still running nulls the status, so the notice flips to "Historical version", which is the finding 2065 mislabel. The deployment panel also stops polling on any read error, so it stays Historical after the API recovers.

Two mutants of the label also survived: a queued deployment and an older version browsed during a deploy were untested (finding 2088).

Change

agents/detail.mjs:

• The version notice labels the newest version from its last deployment record read. A failed read keeps that label instead of falling back to Historical.
• When the deployment completed but the Agent reread failed, the notice now says "Deployed version · read-only admitted snapshot. Its deployment completed, but the current version could not be refreshed." It no longer says Deploying. "Deployed" needs a succeeded record for this activity, a failed Agent reread, and no known newer current version the viewer cannot read; otherwise (a stopped Agent, a reread that never ran, a hidden current version) the label stays Historical. A later successful reread makes it "Current version" as before.
• The deployment panel keeps polling a pending record after a transient read failure: no answer, 408, 429 or 5xx. A refusal or missing record (other 4xx) still ends polling and drops the remembered record, so the label falls back to Historical rather than a stale Deploying. The first read after the failure compares against the last record, so a completion right after a failure still rereads the Agent.

Verification

tests/browser/console-agent-deploy-again.test.mjs:

• Completed, Agent reread fails (new): the notice reads "Deployed …" and never "Historical". Fails on main.
• One failed status read (new): "v2 · Unavailable" keeps "Deploying". The next poll still comes, finds the deployment completed, rereads the Agent, and shows "Current", with no "Historical" at any point. Fails on main.
• Completed record, no failed reread (new, after review): stays Historical, including after a tab round trip. Fails on the previous head.
• Hidden current version, failed reread (new, after review): with v3 current but unreadable and completed v2 the newest listed, Refresh deployment with a 503 Agent reread keeps v2 Historical. Fails on the previous head.
• Refused status read (new, after review): a 403 read gives Historical and polling stops. Fails on the previous head.
• Queued and older version (new): a queued deployment is labelled Deploying, and an older v2 browsed while v3 deploys is Historical. This is a gap test and passes on main.

Other checks:

• Mutation: 11 mutants of the label, notice render and poll in detail.mjs, run at 2 CPUs; 10/11 killed. They include both survivors from finding 2088 and the transient-poll, last-record and reread-failed paths. The survivor never clears the reread-failed flag on a later successful reread; it is near-equivalent, because a successful reread also moves the current version and the label becomes Current anyway.
• Pinning: new and changed tests passed 20/20 at 2 CPUs (8 tests per run).
• Full files: console-agent-deploy-again, console-agent-detail and console-agent-state pass on the current head. eslint, prettier, the Storybook build and docs:check-length are clean.
• Docs: docs/guides/console/agent-details.md and docs/flows/platform-console/agent-editing.md now say polling continues through outages (transient read errors) and stops at a result, a denial or a missing record. Both stay under the 2500-word cap (2498 and 2496).
• Open PRs touching these files (feat(console): move Share Agent into an Access tab #2999 feat: add Gateway managed mode to Agent deployments #2982 feat: share discoverable Driver configuration definitions #2980 fix(runtime): retry network, timeout and 5xx failures of the codex login and model check #2971 feat(console): show the authorized native Gateway people roster #2596 Draft implementation: managed outbound HTTPS for dedicated Gateways #2518 Add OCE policy simulation and tester for network and plugin actions #2445 feat: assign configured OpenClaw roles to Agent users #906): git merge-tree shows no new conflicted file or hunk. feat: share discoverable Driver configuration definitions #2980 conflicts with main but not with this head.

Screenshots, before | after (version-reread-fails: deployment completed, Agent reread 503; version-status-blip: one deployment status read 503 while v2 runs):

state	before	after
version-reread-fails 1440
version-reread-fails 390
version-status-blip 1440
version-status-blip 390

Storybook: two new Pages/Agent detail stories, Deployment completes, Agent reread fails (deploymentCompletesRereadFails) and Deployment status read recovers (deploymentStatusReadRecovers), each with walkthrough steps; both were checked in a headless browser for the expected notice text. The existing deploymentQueued story covers the queued label.

Risks

Low.

• The new "Deployed version" copy appears only after a failed Agent reread, beside the existing "could not be refreshed" error.
• Polling now continues through 5xx and network errors at the existing 5 s cadence, only while the last record was queued or running.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge.

What this changes

The console preserves deployment labels through transient read failures and distinguishes completed deployments whose Agent refresh failed.

Example: v2 completes while v1 remains cached, and the Agent refresh returns HTTP 503.

• Before: v2 still says Deploying beside its completed deployment record.
• After: v2 says Deployed and explains that the current version could not be refreshed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The focused repair resolves the prior findings and has meaningful browser coverage, but the repository's UI evidence gate remains incomplete.
Proof confidence	🦐 gold shrimp (3/6)	Real behavior proof is not required for maintainer- or bot-authored pull requests.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Bug fix · Worth it: Yes · Fix scope: Complete
User problem: An outage can make a deploying version look historical or leave a completed version labelled Deploying.
Reason: The maintainer-authored change repairs contradictory status information within the existing console workflow.

Merge readiness

✅ Ready for maintainer review

This PR fixes two current console read-failure paths and resolves both prior findings; no new actionable code defect was found.

Priority: P2
Reviewed head: a5e37ec40519421ab44b3f4ab75739cc28011906

Before merge

None.

Findings

None.

Tests

• Missing end-to-end proof: The required feature recording showing transient failure, continued polling, recovery, and the failed-Agent-refresh notice is absent; browser regression comparisons are reported by the author but were not rerun.

Agent review details

How this fits together

The Agent detail page reads authorized Agent, version-history, and deployment endpoints, then updates deployment activity and version notices without changing deployment state.

flowchart TB
  Browser[Agent detail page] --> Panel[Deployment activity panel]
  Panel --> API[Authorized controller API]
  API --> Records[Agent and deployment records]
  Records --> Panel
  Panel --> Notice[Version notice]

Loading

Technical review

Best possible solution:

Keep the repair in the existing deployment panel and version-notice owners, preserving hidden-version handling and the distinction between recorded completion and current selection.

Do we have a high-confidence way to reproduce the issue?

Current-main source establishes both failure paths, and the inspected screenshot pairs demonstrate the completed-record label mismatch; no target code was run during this review.

Is this the best way to solve the issue?

The repair uses the existing polling and rendering owners, retains refusal handling, and adds distinct browser cases without changing API or persistence contracts.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against e615044ad212.

Provenance checked

• Deployment version notices keeps the original intent (a70c9e5: fix(console): call a deploying version deploying, not historical #2990 distinguished pending deployments from historical versions and avoided a historical-label flash during activation.)
• Pending deployment polling changes intended behavior with a stated reason (fix(console): follow pending deployment activity until it records a result #746: Automatically follow persisted pending work until completion, stopping on read errors; this PR explains why transient failures should retain the last record and continue polling.)

Testing

Proof path: in-process harness.

Security

None.

Evidence

What I checked:

• Current main retains the reported failure paths: Current main stops deployment polling on any read error and derives the deploying notice from the nullable latest status; the completed-status callback also suppresses notice updates while awaiting the Agent refresh. (apps/controller/src/console/agents/detail.mjs:544, e615044ad212)
• Prior findings resolved: The latest commit restores the known-hidden-current exclusion, adds its browser regression case, and updates both owning documents to describe transient-error polling and terminal stop conditions. (apps/controller/src/console/agents/detail.mjs:1985, a5e37ec40519)
• Focused browser coverage: The changed browser cases exercise completed-record refresh failure, transient status failure and recovery, queued and older versions, hidden current versions, and refusal stopping polling; deployment responses and failures are intercepted, so this proves console behavior rather than worker execution. (tests/browser/console-agent-deploy-again.test.mjs:615, a5e37ec40519)
• Existing feature intent: fix(console): call a deploying version deploying, not historical #2990 established the deploying label; fix(console): follow pending deployment activity until it records a result #746 established pending-record polling and explicitly stopped on read errors; Clarify Agent deployment versions and add on-demand diagnostics #482 separated recorded deployment outcome from current selection and live health. (apps/controller/src/console/agents/detail.mjs, e615044ad212)
• Repository UI evidence requirement: The root policy requires screenshots and a short feature recording as native GitHub attachments before merging UI changes; no nested AGENTS.md or maintainer-notes directory was present. (AGENTS.md:454, a5e37ec40519)
• Inspected visual evidence: The prepared desktop and phone before/after screenshots visibly change Deploying to Deployed beside a succeeded record. They are accessible gist images linked from the PR, rather than native attachments, and the supplied body and discussion contain no feature recording. (/home/runner/work/clawsweeper/clawsweeper/artifacts/event/codex/proof-scratch/3003/media-proof-manifest.json)

Labels

Label changes:

• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.
• remove status: ⏳ waiting on author: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

• P2: Read failures leave misleading deployment notices and stop automatic updates, while explicit page refresh remains available.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR.

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Complete the native UI evidence described in realBehaviorProof.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

History

Review history (2 earlier review cycles)

• reviewed 2026-10-20T04:22:07.251Z sha f0d0416 :: needs changes before merge. :: [P2] Distinguish an unlisted current version from a failed refresh | [P3] Add Storybook scenarios for the changed read-failure states
• reviewed 2026-10-20T04:49:00.777Z sha 3dffcda :: needs changes before merge. :: [P2] Preserve the known-hidden-current guard after a failed refresh | [P3] Update the documented stop conditions for deployment polling

Reviewed October 20, 2026, 1:05 AM ET / 05:05 UTC (Revision 3).

[freeqaz]

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/39371695117
• Updated: 2026-10-20T04:50:42.180Z

[freeqaz]

@clawsweeper re-review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/39373155906
• Updated: 2026-10-20T05:07:21.128Z