You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
π review: digestless perspective reports make every changes_requested verdict look 'body-edited' β hive PRs sit at 070-fixing with fix_kicks: 0Β #14665
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:
/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).
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.
@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.
Activity
π review-fix: dispatch fix kicks when reports carry no body digest
π review-fix: dispatch fix kicks when reports carry no body digest (#β¦
github-actions commentedon Oct 27, 2026
@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
/reopenand 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.