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
gate(eligibility): hold PRs against a priority issue until its window opens (#9738)
Priority issues carry the highest payout, so assignment fairness matters most there -- and first-come
pickup is only fair if everyone can SEE the issue before anyone can act on it. A PR opened moments
after the label lands means the window between "issue becomes valuable" and "issue is claimed" was
effectively zero for everyone else watching the repo.
A PR closing a `gittensor:priority` issue is now gate-eligible only once the label has been publicly
present for `gate.priorityEligibilityWindow` minutes (default 30, per repo, `0` disables it). A PR
arriving inside the window is NOT rejected: it is HELD with a neutral comment naming the moment it
becomes eligible, and proceeds normally once the window elapses. No penalty beyond waiting.
Two decisions worth stating:
- The clock is anchored to the EARLIEST labeling event, not the most recent. The spec requires that
re-applying the label not reset the window for already-open PRs; an earliest anchor gives that to
everyone and makes "when does this issue open for work" a single knowable instant nothing can move.
- Every unknown FAILS OPEN -- an unreadable timestamp, an absent label, a GraphQL error, a missing
token. Holding a contributor's PR on a fact we could not read is a penalty for our own gap.
The hold reuses the existing merge-hold rail (`heldForManualReview`), so it can never close a PR.
Merge holds become DATA rather than a widening list of booleans. `MERGE_HOLD_INPUTS` is the one
table; the input type (`Record<MergeHoldInput, boolean>`), the `heldForManualReview` fold, and both
test fixtures all derive from it. Adding a hold was three independent edits that could each be
forgotten -- declaring one and not folding it into the decision compiled fine. It is now one entry,
and omitting the wiring is a compile error at the single call site.
`normalizeOptionalNonNegativeInteger` exists because `0` is meaningful here (it turns the rule off)
and the positive-integer normalizer would have discarded it as invalid and silently applied the
default -- an operator's explicit "off" becoming "on".
100% statements and branches on both changed source files.
0 commit comments