Skip to content

fix(ci): preserve valid staged sweeps across relabels#2180

Merged
cquil11 merged 1 commit into
mainfrom
agent/fix-stage-label-window
Jul 13, 2026
Merged

fix(ci): preserve valid staged sweeps across relabels#2180
cquil11 merged 1 commit into
mainfrom
agent/fix-stage-label-window

Conversation

@cquil11

@cquil11 cquil11 commented Jul 13, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • validate a staging source run against the full-sweep labels active when that run was created
  • keep requiring a current full-sweep label, write access, a PR-owned commit, successful completion, changelog metadata, and unexpired benchmark artifacts
  • avoid retroactively invalidating a completed sweep when the same label is temporarily removed and reapplied

Why

PR #2157's successful run 29181694248 was created while full-sweep-enabled was active. The label was later removed for nine seconds and reapplied, causing the staging gate to reject that older valid run as predating the current label.

Validation

@cquil11 cquil11 requested a review from a team July 13, 2026 21:58
@cquil11 cquil11 merged commit 058f18c into main Jul 13, 2026
4 checks passed
@cquil11 cquil11 deleted the agent/fix-stage-label-window branch July 13, 2026 22:10

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM — the label-state replay logic correctly reconstructs which full-sweep labels were active at a given run's creation time, based on independent reading of the diff.

Extended reasoning...

Overview

Single-file change to .github/workflows/stage-results.yml, the /stage-results staging-gate workflow. It replaces a single 'most recent labeled event' timestamp check with a proper replay of the PR's labeled/unlabeled timeline events to determine which full-sweep labels were active at the moment a candidate sweep run was created. All other checks (write-access authorization, PR-owned head commit, current full-sweep label presence, run success, changelog metadata, unexpired benchmark artifacts) are unchanged.

Security risks

None introduced. The write-access permission check and the cross-repo dispatch using INFX_FRONTEND_PAT are untouched by this diff — only the temporal validation of which historical run qualifies for staging is modified. Worst-case failure mode of a logic bug here is an incorrect accept/reject of a staging candidate, not a privilege escalation or credential exposure.

Level of scrutiny

This is CI-gating logic, not production/serving code, so the bar is bug-fix correctness rather than deep security review. I traced the new fullSweepLabelsAt replay algorithm by hand: it sorts labeled/unlabeled events ascending, iterates until an event's timestamp exceeds the candidate's created_at, and maintains a Set of active labels — this correctly reconstructs point-in-time label state and fixes the described bug (a run wrongly invalidated by a brief unlabel/relabel after it completed). I did not find edge cases beyond what the bug hunting system already ruled out (the PR-creation-time-labeling scenario).

Other factors

The author validated the fix by replaying PR #2157's actual label timeline against the new logic (documented in the PR description) and via actionlint. The bug hunting system found zero issues and explicitly investigated and refuted one candidate concern. Change is small, self-contained, and does not touch authorization or dispatch code paths.

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

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

1 participant