Repository navigation
fix(console): show a watched deploy failure as a reload does - #3008
Conversation
A deploy that failed while the Agent page was open put the 'Deployment needs attention' card below the auto-expanded Deployment details, below the fold at 1440, and the error showed three times; a reload put the card first (finding 2094). The card now keeps its place at the top on a live failure too, and the first time it shows for a failed version the Deployment details fold, since the card carries the error and its next step. This reverses finding 1655's placement: the overview moves down once when the failure lands, as the brief for 2094 asks.
…sit beside new imports
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
clawsweeper
Bot
added
clawsweeper:intake:bug
|
Codex review: needs maintainer review before merge. What this changesThis PR puts watched deployment failures first on the Agent page and folds redundant details while preserving cleanup, startup warnings, and refresh errors. Example: Version v2 fails its startup model check while v1 remains selected.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep open: this PR fixes a concrete console inconsistency that remains on main. The previous refresh-warning finding is resolved, and no remaining code defect was identified. Priority: P2 Before mergeNone. FindingsNone. Tests
Agent review detailsHow this fits togetherThe console Agent detail view consumes deployment records and Agent/version reads, then renders recorded outcomes, recovery actions, and supporting evidence. flowchart TB
A[Deployment poll or Refresh] --> B[Deployment and Agent reads]
B --> C[Deployment status panel]
C --> D[Agent overview]
C --> E[Failure recovery card]
E --> F[Conditional details fold]
Technical reviewBest possible solution: Keep the focused presentation fix and its exceptions for evidence that the recovery card does not contain. Do we have a high-confidence way to reproduce the issue? Current main explicitly relocates watched failure recovery below deployment activity; the supplied screenshots and reported browser regression demonstrate the corresponding layout difference, although no target code was run during this review. Is this the best way to solve the issue? The patch uses the existing recovery card and disclosure owners, preserves distinct cleanup and warning evidence, and replaces the old placement assertion with watched-versus-reloaded coverage. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against bd52601ef238. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale6/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. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReview history (6 earlier review cycles)
Reviewed October 20, 2026, 2:58 AM ET / 06:58 UTC (Revision 7). |
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
clawsweeper:intake:bug
With Share Agent on its own tab (#2999) and the details folded, the error shows once, on the card, and the version detail can start in the lower half of the first screen at 1440. The recovery link tests now require only that it starts outside the upper half, which their in-view check needs.
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
clawsweeper:intake:bug
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
clawsweeper:intake:bug
A Refresh deployment that read a failure while its Agent or versions read failed opened the details for the 'could not be refreshed' warning, and the card's fold closed them at once. A panel showing that warning now stays open, like one with a cleanup or startup warnings.
|
Fixed the later P2 in d0503a3: a failed record read by a Refresh whose Agent or versions read fails left the "Current version and version history could not be refreshed" warning folded away.
|
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
clawsweeper:intake:bug
freeqaz-openai
left a comment
freeqaz-openai
left a comment
There was a problem hiding this comment.
Verified the cleanup visibility fix I requested, and the partial-refresh warning fix, on d0503a3. Thank you.
In the browser, a watched deployment failed while the Agent overview read returned a controlled 503. On b553fb9 the warning was present but hidden; on this commit the details open and the warning is available without a click. I also checked that pending cleanup stays visible, an ordinary failure starts folded, and refreshing after I open the details respects that choice.
This resolves my specific objection in review 5581365985. These were controlled Console checks, not a live deployment or a substitute for the required human review. I would not hold this fix for a separate disclosure-state refactor.
Problem
Dogfood round 32 (finding 2094, D664, medium): when a deploy fails while the Agent page is open, the "Deployment failed" card lands below the overview and below the auto-expanded Deployment details, about 960 px down at 1440 (1,550 px at 390), and the failure's error text shows three times (card, Deployment details, the version's record). A reload of the same page puts the card first, under the header. Finding 1655 had moved the live card down there to avoid pushing the overview while the reader watched; with the details expanded that put the next step below the fold.
Change
agents/detail.mjs: a failure that lands while the page shows keeps the card where a load puts it, first in the page. The first time the card shows for a failed version, the Deployment details fold: the card already carries the code, the API's message and its next step. The reader can open the details again and they stay open. The card sits inside the view's polite live region, so its appearance is announced; the details' alert no longer repeats it.docs/reference/console/versions-and-channel-drafts.md(where docs(console): split near-cap console reference and flow pages #3013 moved the section) anddocs/guides/console/agent-details.mdsay a failure's card leads the page and folds the details;npm run docs:check-lengthand the docs link check pass. ThedeploymentFailsWhileWatchingscenario's description and steps describe the new placement and the fold.This deliberately reverses 1655's placement: the overview moves down once when the failure lands, which is what the brief for 2094 asks ("render the same as a fresh load"). The folded details give most of that height back to the cards below.
Verification
watched: {leadsOverview:false, top:957, detailsOpen:true, errorShown:3}vs reload{true, 180, true, 3}at 1440;top:1553at 390) and passes with the fix; 20/20 at 2 CPUs.Media (fixture: v1 current, v2 deploying, then its model check fails and Refresh deployment reads it; first screen, and the whole page at 1440):
Risks