The CI-red corrective loop hands the implementer no log at all — every retry after a red build is a blind guess #411
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
toasterson/Anima!411
Loading…
Reference in a new issue
No description provided.
Delete branch "claude/wi-019fa902-the-ci-red-corrective-loop-hands-the-imp"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Anima work item
019fa902-43b4-7283-a662-8da24798f35f.Symptom
When CI goes red,
handle_job_failureappends a "CI Failure (attempt N)" block to the work item's description so the corrective context rides the implementer's next forcing prompt. That block contains one line and no log. Every such revision written today, measured on 2026-07-28:Six revisions, 180–192 bytes each. The template's own prose — "Fix the failure below, then push again." — is followed by nothing to fix. The implementer is told a build failed and is given no compiler error, no failing test name, no assertion, no stack.
WI-413 has burned three CI attempts this way and WI-315 two. Each attempt is a full session: a slot, a clone, a build, a push, a CI run. The retry cannot converge because the loop never tells the agent what broke.
Root cause
The wire type carries no log.
JobResult(vendor/solstice-ci/crates/common/src/messages.rs:166) hassuccess,exit_codeandsummary: Option<String>— and no log field of any kind. Anima's shim makes that explicit:So
tail_lines(&result.combined_log_or_default(), 60)atsolstice.rs:546asks for the last 60 lines of a string that is at most one line long, and usually is the runner's own top-level "workflow failed" line rather than anything from the build.summaryisnulloutright on some results.The logs do exist — solstice stores them per step;
list_steps/tail_step_logserve them forsource=forgejoruns. They are simply never fetched for the native (solstice_dispatch) lane, which is the lane every Anima work item uses. A native run'srequest_idis not resolvable throughsolstice-mcpeither (run not foundfore34b42b0-a065-40d1-aa50-44896c077aca), so the native lane's logs are currently unreachable from Anima and from the operator tooling.Ask
JobResultwith the tail the runner already has in hand, or have Anima fetch it byrequest_idfrom solstice after the result lands. Prefer the fetch: an unbounded log on a message bus is its own problem, and the fetch also gives the operator surface back.request_idin solstice's job/step store, solist_steps/tail_step_logwork for them the way they do for the Forgejo lane.combined_log_or_default()silently substitutingsummary(andsummarysilently substituting"") is what made this invisible for as long as it has been. If no log can be retrieved, say so in the corrective block — "CI failed and no log could be retrieved (request_id=…)" is honest; a code fence containing one line of nothing is not.failed_dispatch_countclimbs toward the park cap on evidence the agent was never shown.Acceptance criteria
cargo testcontains the failing test's name and its assertion output.error[EXXXX]block and the file:line.tail_step_logreturns step output for a nativesolstice_dispatchrun given itsrequest_id.JobResultwithsummary: Nonemust not produce a corrective block that claims to contain a failure.Related
WIP: The CI-red corrective loop hands the implementer no log at all — every retry after a red build is a blind guessto The CI-red corrective loop hands the implementer no log at all — every retry after a red build is a blind guess