Repository navigation
fix(worker): log why an exhausted active revision pass failed - #3352
Conversation
continueExhaustedActiveRevision ended a published deployment's last retry (and an exhausted maintenance pass) with a worker.completed line that had no failure fields, unlike every other ended pass. Pass the pass's failureLogFields through so the line carries cause/dependency/status. Tests: a shared withUnavailableIAM helper replaces three inline copies of the IAM-outage driver; the exhausted repository maintenance case and two new exhausted-published-deployment cases assert the logged cause. The new cases pin today's behaviour of queuing no maintenance chain, which is finding 1743's open design question.
|
🦞👀 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. |
|
Codex review: needs maintainer review before merge. What this changesThis PR adds existing failure diagnostics to exhausted active-revision pass logs and shares the tests’ IAM-outage fixture. Example: An active revision’s maintenance pass exhausts its attempts while IAM throws an Error.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open: it repairs a current diagnostic omission with a focused change, and I found no introduced correctness or security defect. Priority: P2 Before mergeNone. FindingsNone. Tests
Agent review detailsHow this fits togetherThe durable controller worker consumes PostgreSQL revision work, reconciles Agent runtimes through Drivers, and emits structured completion events for operators. flowchart LR
A[PostgreSQL work queue] --> B[Controller worker]
B --> C[Revision reconciliation]
C --> D[IAM and Compute Drivers]
D --> E[Failure classification]
E --> F[Exhausted active revision completion]
F --> G[Structured worker log]
Technical reviewBest possible solution: Preserve the existing continuation lifecycle and forward its already-classified diagnostics through the existing completion event. Do we have a high-confidence way to reproduce the issue? Current main demonstrably drops failureLogFields on the exhausted-active-revision branch; the PR reports three assertions failing on base and passing after the fix, but I did not execute tests. Is this the best way to solve the issue? Forwarding the existing safe diagnostics at the existing owner is the smallest complete repair; the separately acknowledged maintenance-chain question need not expand this logging fix. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 5370e972f8b1. Provenance checked
TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
Likely related people:
Review metrics
LabelsLabel changes:
Label justifications:
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 Reviewed October 23, 2026, 4:20 PM ET / 20:20 UTC. |
Problem
When a deployment has already published the active pointer and its last retry fails (or an active revision's maintenance pass exhausts its retries),
continueExhaustedActiveRevisionends the pass with aworker.completedline that carries no failure fields. Every other ended pass logscause(plusdependency,statusand the rest when known), so an exhausted post-publish deploy or maintenance pass during an outage logged onlycode: DEPENDENCY_UNAVAILABLE, with no hint of what failed.Change
apps/controller/src/worker.ts:finalizeRevisionpasses itsfailureLogFieldsintocontinueExhaustedActiveRevision, which spreads them into itsworker.completedline, for both:reconcileand:maintenance:Nkeys. No other behaviour changes.withUnavailableIAM(unavailable)driver transform intests/helpers/postgres-worker-revision-support.mjsreplaces three inline copies of the IAM-outage driver (two in the teardown file, one in the credential-sources file).cause. Two new cases cover an exhausted deployment of the published active revision, with and without a declared maintenance interval. They assert thecause, that the runtime keeps running, and that no maintenance is queued.Open, not in this PR: whether that exhausted deployment should also start the revision's maintenance chain. Today it doesn't, so the published runtime has nothing checking on it until the next deploy. Queuing maintenance on its own would be wrong: the maintenance gate ends any pass whose
:reconcilework failed asREVISION_SUPERSEDED, and for repository revisions that retires the running runtime. That needs a design decision. The new cases pin today's behaviour (no maintenance queued) and point at the question, so a fix will have to update them on purpose.Verification
causeisundefined) and pass with the fix.postgres-worker-agent-revision-teardown.test.mjs: 31/31 on local PostgreSQL, then pinned 20/20 at 2 CPUs (the later commit only edits a comment).postgres-worker-agent-revision-credential-sources.test.mjs: 43/43. Its two cases that use the helper are pinned 20/20 at 2 CPUs.tsc --build tsconfig.json tests/tsconfig.json, eslint and prettier are clean on the touched files.Risks
Low. This is one more set of log fields on an existing line, plus a test-only helper refactor. The new fields are the same ones the other ended passes already log; none of them is a secret.