Skip to content

πŸ› review: digestless perspective reports make every changes_requested verdict look 'body-edited' β€” hive PRs sit at 070-fixing with fix_kicks: 0Β #14665

Closed

Description

@clubanderson

Symptom

Hive-authored PRs whose swarm verdict is changes_requested are routed to stage/070-fixing but no fix kick is ever planned: every review-swarm cycle logs fix_kicks: 0, no review fix dispatch excluded line is written for the PR, and the dashboard shows "Fixing" indefinitely.

Observed on hosted-available-oke-11-placeholder-r05x (build 6977027), 2026-10-27:

PR verdict (artifact) 070 since planner cycles since fix kicks
#14614 changes_requested (intent-alignment), all 5 perspectives recorded 17:34Z 17:55Z (reviewer-verdict:changes_requested) 17:50, 18:07, 18:19Z 0
#14630 changes_requested (correctness), 5/5 recorded 18:15Z 18:20Z β€” 0 (same path)

Instead of a fix, the planner keeps the old pending_reviews entry alive and later expires it as a redispatch:

18:19:49 review pending expired repo=hivecommons/hive pr=14614 perspective=security agent=ci-maintainer age=54m41s expiries=1
18:19:49 review swarm dispatch planned review_kicks=3 fix_kicks=0

/data/review-dispatch-state.json: redispatches: [{number:14614, head:4cae37e7, count:1, last_expired_at:18:19:48Z}], fix_attempts has no entry for 14614; the merge gate meanwhile reads the same artifact and holds with changes-requested:intent-alignment.

Root cause

PlanDispatch (src/pkg/review/dispatch.go ~570) only reaches dispatchFix when
!staleVerdictRevisitable(...) && !bodyEditedVerdictRevisitable(pr, agg).

bodyEditedVerdictRevisitable (dispatch.go:989):

if strings.TrimSpace(pr.BodyDigest) != "" && strings.TrimSpace(agg.BodyDigest) == "" {
    return true
}

The PR always carries a body digest (the pending entries record body_digest: e98707ff… for 14614). The aggregate's digest comes only from the perspective reports (review.go:389-394), and the reviewer prompt tells agents they may "copy it verbatim into body_digest or leave the field out" (prompts.go:289). On this hive every report for 14614 and 14630 left it out β€” /data/review-reports/review-report-hivecommons-hive-14614-*.json have keys lane, kind, findings, prs_opened, beads_filed, summary, perspective, verdict, repo, number, head_sha, author_model, review_model, concrete_remediation and no body_digest; /data/review-verdicts.json items likewise have no body_digest.

So every non-approve verdict with digestless reports is treated as "body edited since the verdict" β†’ the planner takes the revisit branch (re-ask the perspectives) instead of dispatchFix, forever. Approve verdicts are exempt (line 990), which is why merges still work and only the fix cycle is dead.

The stage-label router (stage labels: reviewer verdict route) and the self-merge gate read the aggregate without this check, so the label says 070-fixing while the planner never fixes β€” the dashboard "Fixing" pill is untruthful.

Expected

  • A digestless aggregate must not count as "body edited". Fall back to the UpdatedAt > RecordedAt comparison (line 999) or treat missing-digest as a match when a single digest group exists for the head (same spirit as foldDigestlessReports).
  • Better: stamp BodyDigest onto the aggregate from the PR snapshot / pending entry at collect time instead of relying on the agent to echo it.
  • A revisit decision that suppresses a fix kick should log a review fix dispatch excluded reason (verdict-revisit:body-edited) so an operator can see why fix_kicks: 0.

Not the same as #14604 (PendingFix never expiring β€” there is no PendingFix here) or #14607 (conflicting masks decision_requested).

Found during a read-only tracker audit; evidence files kept by the operator.

Activity

  1. added a commit that references this issue on Oct 27, 2026
    5ed9908
  2. added a commit that references this issue on Oct 27, 2026
    93ed1f5
  3. github-actions commented on Oct 27, 2026

    @github-actions
    Contributor

    @clubanderson this issue was closed by @hivecommons-hive[bot] as completed.

    If this was closed by a merged PR, the fix only takes effect once it ships in a tagged release and your deployment updates to it β€” check your running version against the fix before concluding the fix failed.

    If you are still seeing the problem, comment /reopen and it will be reopened for you β€” you do not need write access. Please add what you are still observing (running version, logs, steps) so it is not closed the same way again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions