Repository navigation
🐛 fix(dashboard): only badge issues as regressed when they actually regressed - #14571
Conversation
…ressed A lapsed claim (020 -> 010/015), the claim's PR-evidence flicker (030 -> 020), the agent returning to its covering PR (040 -> 030) and a 040 -> 010 fall after the covering PR merged partially (hive/partially-addressed) were all booked as regressions by IsRegression, so freshly filed, never-worked issues wore a red 'regressed' chip at Actionable. The marker also only cleared once the item climbed back to the exact stage it fell from. - IsRegression: leaving the 020 reservation is never a regression; 030 -> 020 and 040 -> 030 are not falls. - Decision.Progress / Store.ObserveProgress: a fall to 010/015 on an issue carrying hive/partially-addressed is progress, not a regression. - The marker clears on the first forward hop (and on a progress fall, or when the recorded fall no longer counts under the current rule), in the same tick as the stage write. - Dashboard: the chip is red only on human-gated rows; otherwise a muted dashed 'stage ↓' pill with an explanatory tooltip, outside Needs attention. - Lifecycle (set / kept / cleared) documented. Fixes #14570 Signed-off-by: Andy Anderson <andy@clubanderson.com>
kubestellar-prow
Bot
added
the
dco-signoff: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
kubestellar-prow
Bot
added
the
size/XL
|
@clubanderson is auto-promoted for contributor-lane merging on this PR: the last 5 merged PRs by this author in this repository have no revert or sentinel-alert evidence. CI, reviewer verdict, diff fences, soak, holds and branch protection still apply. |
hivecommons-hive
Bot
added
author/human
… a regression The three tests that asserted the old rule (any backward hop out of 020 is a regression) now assert the new one, and the RegressionHop test expects the 040 → 020 fall to stay the record's only regression across the later 020 → 010 slide. Signed-off-by: Andy Anderson <andy@clubanderson.com>
hivecommons-hive
Bot
added
stage/071-needs-author
|
@clubanderson this PR is held at Failing checks:
Next: the hive does not push to your branch. Push a new head (or reply here); CI and the review swarm re-run automatically and the PR returns to the normal path. |
hivecommons-hive
Bot
added
stage/050-review-pending
![hivecommons-hive[bot]](https://avatars.githubusercontent.com/in/3568013?s=60&v=4){kind=small}
There was a problem hiding this comment.
Read the diff against v5 (6977027a8): stagelabels/store.go ObserveProgress + the three new IsRegression cases, stageengine/derive_issue.go issueProgress, both call sites (stageengine/reconciler.go:156, github/issue_stage_labels.go:472), and the index.html modifier/attention changes. The store logic is sound: the forward-hop clear (prev.Stage.Before(stage)) and the "non-regression backward hop neither books nor clears" path (!IsRegression(prev.RegressedFrom, stage)) behave as the comment describes for 040 → 020 → 010. In the frontend, mods.push(mods.shift()) always rotates regressed because stalled (the only higher-priority modifier) is in STAGE_TRACKER_HUMAN_MODS, so handled is never true with stalled present. Looks correct to me.
One trade-off worth having on record, not a blocker:
issueProgress keys off a sticky label, so it also suppresses later genuine falls — src/pkg/stageengine/derive_issue.go:142-147 (low)
issueProgress returns true whenever the stage is 010/015 and the issue carries hive/partially-addressed, regardless of what caused this fall. That label is only removed when a later PR fully lands (src/pkg/github/close_on_merge.go:585-589), and src/pkg/github/prclaims.go:1855-1861 adds it for reference-only (claim.Reference) issues too. So once an issue wears it, a subsequent 030 → 010 ("agent announced a PR and vanished") or 040 → 010 (second covering PR closed unmerged) is reported as Progress and never badged, and ObserveProgress also clears any regression already open on it. For #14557/#14550 this is the intended outcome; for an epic that is referenced by PRs and then has a claim lapse, the regressed badge is permanently off. If that matters, issueProgress would need to look at the covering PR's merged state rather than the label. Fine to land as-is if the owner is happy with that precision loss.
— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88
Open PR overlap checkBase branch: Conflicts are checked with every PR merged onto the current tip of
|
github-actions
Bot
added
the
conflicts-with-open-pr
hivecommons-hive
Bot
added
stage/071-needs-author
|
@clubanderson this PR is held at Failing checks:
Next: the hive does not push to your branch. Push a new head (or reply here); CI and the review swarm re-run automatically and the PR returns to the normal path. |
|
merged by Hive trusted-author auto-merge: author @clubanderson holds role owner and GitHub permission admin on repo; CI green at e7ed0d6. |
hivecommons-hive
Bot
removed
role/trusted
|
Thank you for your contribution! Your PR has been merged. We'd love to hear how your experience was: share feedback |
Second-round catch-up for #14340: the 7 v5 commits that landed after the main forward-merge (#14585 credit issue authors, #14583, #14579 merge gate follows live sentinel label / HumanApprover, #14580, #14571, #14427, #14428). Hand-resolved (16 files): - stagelabels/human.go: union of v6 Route.ManualMerge and v5 HumanApprover, ManualMergeRule, LaneReason. - config: v5 auto_merge.credit_issue_authors applied in review_config.go (v6 moved AutoMergeConfig there). - github/review_evidence*: v5 (blocked param, Notice = !blocked); sentinel_sweep.go keeps v6 adoption handling with the v5 one-line change. - automerge: linked-issue gate (v6 #14184 fallout) now seeds the v5 MergeCreditor's author cache so a merge-ready PR costs one issue GET; v5's lane-side decisionActions test dropped (v6 renders actions in stagelabels.DecisionActions). - dashboard/stage_tracker.go: v5 #14579 stageTrackerSentinel supersedes v6 #14053 (cleared label: alert off, findings still fill the tooltip). - dashboard/server.go: v5 FleetRun + v6 AdmissionLabels; index.html: v5 attention title + v6 "Hive end to end first" sort. - docs: v5 text with v6-only sentences re-applied; api-reference citations regenerated. Signed-off-by: Andrew Anderson <andy@clubanderson.com>
Fixes #14570
Why
Freshly filed, never-worked issues (#14558, #14559, #14554, #14557; later #14525, #14550, rationguard#396) wore a red
regressedchip on the stage tracker. Owner: "actionable items that show 'regressed' are odd to me. makes me think I need to take action." / "shouldn't the regressed label come off the issue/pr if it is moving ahead?"Root cause
src/pkg/stagelabels/store.goIsRegressiontreated every numerically backward hop as a regression bar a short exception list, andStore.ObservebookedRecord.RegressedFromon each one;src/pkg/dashboard/stage_tracker.goturnsrec.Regressed()into theregressedmodifier. Three ordinary hive moves were caught:live claim with a PR under way↔live agent claim (no PR yet), every ~15 min)hive/partially-addressedThe marker then only cleared once the item climbed back to the exact stage it fell from, and the frontend always painted it red and counted it under Needs attention. No GitHub label is involved (
stage/regressedis retired and already stripped same-tick).Fix
Detection (
stagelabels/store.go,stageengine/{decision,derive_issue,reconciler}.go,github/issue_stage_labels.go)IsRegression: leaving 020 is never a regression; 030 → 020 and 040 → 030 are not falls (030 → 010/015 and 040 → 010/015/020 remain regressions).Decision.Progress+Store.ObserveProgress: a fall to 010/015 on an issue carryinghive/partially-addressedis progress, not a regression. Wired through both the central reconciler and the legacy sweep (the live path).Self-clearing
GET /api/stage-tracker.Dashboard (
static/index.html)stageTrackerRegressionHandled(item): regressed, no human-gate modifier (hold,needs-human,needs-decision,needs-rebase,blocked,stalled) and not on 045/071/072/085/090 → muted dashedstage ↓pill (.ham-mod-handled), tooltip = fall detail + "the hive is handling it — no action needed; clears on the next forward step", yields the lead slot to any other modifier, excluded from Needs attention, no "Sent back" headline.regressed+ "Sent back" reserved for human-gated rows.Docs: lifecycle section "The regressed marker: when it is set, when it clears" in
labels-and-control-signals.md; stage-tracker paragraph indashboard-sections.md; diagram edge annotations.Tests (table-driven, no
time.Sleep)stagelabels/regression_reservation_test.go:TestIsRegressionReservationStages,TestStoreObserveProgressFall,TestStoreObserveClaimLapseNoRegression(020 → 010 replay, stale-record heal, 030 ↔ 020 flap loop),TestStoreRegressionClearsOnForwardHop(lifecycle walks).stageengine/regression_progress_test.go:TestDeriveIssueProgress,TestReconcileProgressFallBooksNoRegression(replays [scanner] repeat-failure: command normalization and sliding-window detector (monitor-only) #14557 through the real reconciler: merged-partial vs closed-unmerged).dashboard/stage_tracker_regressed_test.go+stage_tracker_ui_test.go: handled vs red cases, attention filter, headline.TestStoreObserveRegressRecoverAndStalledadapted to forward-hop clearing.