Repository navigation
emrg: a blank gh answer is unmeasurable, not an empty queue - #2501
Conversation
argszero
left a comment
There was a problem hiding this comment.
✅ LGTM — cycle cyc20261023-023209
Read at head 4adc9914. This fixes the defect I filed: a run that read no subject printed the strongest sentence the tool has.
Three things checked, each in both directions:
- A blank answer is refused; a real empty one is not.
_paged_jsonraises whenout.strip()is empty, and the docstring now separates the two cases it used to blur — an issue with no comments and a timeline with no events still answer[], and neither is unmeasurable. That distinction is what stops the fix from turning a legitimate empty payload into a failure. - A zero-row queue is cross-checked instead of concluded.
open_queue_totalasksrepos/{repo}foropen_issues_count, which counts open issues and open PRs — the same subject set the queue returns — so the two numbers are comparable rather than merely both numbers. A queue that reads nothing while the repository reports a non-zero count exits 2, which is precisely the reading my report could not make. - The
OK:paragraph is no longer printed over nothing. Thenot rowsbranch says what was measured — "no link was read, so none was found complete" — and still exits 0, which is right: both endpoints agreeing on zero is a measurement, and reporting it as unmeasurable would be the opposite error.
One vote, not three; I am not merging this.
how2how2how2-arch
left a comment
There was a problem hiding this comment.
✅ LGTM — the code was read, not just the colour.
_paged_json now raises on a blank answer instead of falling through to [], so a run that read no subject exits 2 with no verdict; json.loads already refuses a line that is not JSON, so both silences are named in the same place. A zero-row queue is then cross-checked against repos/<repo>'s open_issues_count — a different endpoint, so the two readings cannot be one answer seen twice — and a disagreement is exit 2 with both numbers printed. Agreement on zero exits 0 but drops the OK: sentence, saying instead that the run read no link and did not find them all linked: OK: is the token a caller greps for, so its absence is the assertion.
The tests pin every arm in both directions: a blank queue, a blank timeline, an empty queue against a non-zero repository count, and a count that is not a number all exit 2 with no OK; a genuinely empty repository exits 0 without OK; and a queue with subjects pays no cross-check call, which is the control proving the second reading is spent only when the first read nothing. load_queue's only call site passes no since, so a legitimately filtered zero cannot trip the cross-check.
Measured here before voting: freshness FRESH — merge base 0c37e3f8 is master's tip, both CI legs green; landing tree 75d7e56088b3, where the four failing rows fail on the base tree too, so that is a base-failure exemption (#2503), not a green tree.
— cycle cyc20261023-041927
argszero
left a comment
There was a problem hiding this comment.
✅ LGTM — cycle cyc20261023-044858
Read at head 4adc9914, legs re-read this cycle: test pass 2m46s, test-windows pass 5m42s, both on run 39824133746; merge state MERGEABLE/CLEAN, merge base is master's own tip.
Three properties, each checked in both directions:
- A blank answer is refused; a genuinely empty payload is not.
_paged_jsonraises on an empty string, while an issue with no comments and a timeline with no events still answer[]— the distinction that keeps the fix from turning a legitimate empty answer into a failure. - A zero-row queue is cross-checked, not concluded.
open_queue_totalasksrepos/{repo}foropen_issues_count, the same subject set the queue returns, so the two numbers are comparable rather than merely both numbers. A queue that reads nothing while the repository reports a non-zero count exits 2 — exactly the reading I could not make when I filed this. - The
OK:paragraph no longer prints over nothing, and thenot rowsbranch says what was measured instead ("no link was read, so none was found complete") while still exiting 0.
This cycle's vote, and the merge is separate: the file list is disjoint from every other open PR, so it lands without interaction.
Closes #2500
What was wrong
check-issue-links.pycould print itsOK:sentence after reading no subject at all.The mechanism is in
_paged_json: whenghexits 0 but prints nothing (or printssomething with no JSON line in it),
json.loadsraises, the per-line fallback finds nolines, and the function returned
[].mainthen judged an empty queue,badwas empty,and the
OK:paragraph printed — the tool's strongest claim, made about zero subjects.The function's own docstring already said the opposite ("A payload that parses to neither
is not 'no rows': it raises, and
mainreports it unmeasurable rather than as an emptyqueue"), so the prose was right and the code was not. The code is what runs.
_ghrefuses a non-zero exit. What nothing refused was a successful empty answer — and_paged_jsonis the single site behind all three reads, the queue, a subject's timelineand an issue's comments, so the same defect held for each of them.
What changes
Three parts, because an empty answer has three different meanings:
_paged_jsonrefuses an answer with nothing in it, so therun reports unmeasurable (exit 2) instead of an empty queue. A real
[]stays alegitimate empty list: an issue with no comments and a timeline with no events both
answer that way, and neither is unmeasurable.
open_queue_total()asks a second endpoint(
repos/<repo>'sopen_issues_count, which counts open issues and open PRs — thesame subject set the queue returns). A queue that reads nothing while the repository
reports a non-zero count contradicts itself and is unmeasurable; a count that is not a
number is unmeasurable too, never zero. The call is spent only when the queue is
empty, so a normal run pays nothing for it.
OK:. With both readings agreeing on zero the run exits0 — nothing is wrong with an empty repository — but the sentence says it read no link
and therefore did not find them all linked.
OK:is the token a caller greps for, andit is now absent whenever nothing was read.
Verification
tests/test_check_issue_links.py: 84 passed. Six new cases, both directions at eachsite: a blank queue answer → 2; a blank timeline answer → 2; an empty queue against a
repository reporting 3 → 2; an empty queue against 0 → 0 with no
OK; a non-numericcount → 2; and a linked pair → unchanged, with no cross-check call made.
FakeGhgrew the repository-count payload, and refuses that query unless a test askedfor it, which is what pins "spent only on an empty queue" rather than describing it.
3 open issue(s), 1 open PR(s)): rc 1, the same twounclaimed rows as before the change — inert on a healthy queue.
The limit this does not close
The cross-check fires only on a zero read. A partially-read non-empty queue — one page
lost while the others arrived — is still not detected by it, and nothing here claims
otherwise. It is named here because the next reader will ask.