Repository navigation
Instrument traps: three from review, where the instrument was correct under its own definition - #9140
gunbai-bot[bot] wants to merge 4 commits into
Conversation
… under its own definition The brief's existing specimens are mostly measurements. These three are REVIEW instruments — the tools you reach for to decide whether someone else's work is done — and they share a shape the measurement specimens do not make explicit. 1. A PR reported ready=True carrying three REQUEST_CHANGES in its history and none on its head. Readiness counts only current-head reviews, so the flag was right under its own rule; the question being asked is whether the objection was ADDRESSED, and a push does not answer a review, it makes it stale. Eight of 40 open PRs carried a provider whose last verdict was request_changes on a stale sha; five had checks as their only unmet requirement, so an unrelated main fix would flip all five at once. On the worked example, one stale finding was genuinely fixed and one was still live — both outcomes possible, only reading decided which, and the flag's green is produced the same way either way. 2. Sweeping for that pattern, stale_provider_count returned ten. It counts any provider off-head INCLUDING ONES WHO APPROVED — one stale verdict was an approve, so counting it attributes an objection to someone who did not make one. Filtering on last-verdict-per-provider cut ten to eight, and to five that would actually flip. The inflated number was already written into a report before I checked what the field counted. 3. Checking an asserted "leaf entry point, like its siblings" parallel, an unbounded grep returns four hits for one sibling and three for the other against zero for the subject — parallel false, witness wrong. With a word boundary, all three return zero — parallel holds. All seven were realize_provision_* , a different symbol containing the first as a substring. The unbounded form did not return a slightly wrong count; it returned the OPPOSITE CONCLUSION. The asymmetry is the reason this is one section rather than three footnotes: in two of the three, the wrong answer was cheaper to reach AND more interesting to report — more affected PRs, a caught-out author. Both cheap answers pointed toward having found something. That is not a reason to trust them; it is the reason they were cheap. Counts re-measured against the PR head before publishing; an earlier draft of this section said "three for each sibling", which was the figure for one of the two.
…rrect Measured by crisp-crab-430 during the namespace cut; recorded with attribution rather than left in a message, because two findings died with their sessions today and attribution is reversible where loss is not. The three existing specimens all fail in the expected direction — the instrument misses something — so the correction ADDS findings. This one inverts: a naive scan for a lambda-parameter defect returned 109 matches across 34 files and 108 were correct code, because uppercase before => is a qualified variant PATTERN and only lowercase binds. Rewriting all 109 would have been a 108-site regression committed in the name of a one-site repair, and it would have COMPILED. The lesson is distinct rather than additional: 109 is the correct answer to the question the scan asked. Volume reads as thoroughness, so the high-count result is the dangerous one, and precision is the half of the instrument that never appears in its output. Every earlier specimen is caught by asking 'did I miss any'; this one only by asking 'of what I found, how many are the thing' — a question nothing about a large result set prompts. Carries the author's root, which is better than the specimen: A NAME THAT BINDS IS NOT A NAME THAT REFERS. It also explains the 108 — they were the same binding-versus-referring distinction on the healthy side, which is why a shape-level scan could not separate them.
|
No fix to push — this failure is not in this PR. Verified rather than assumed. This is a docs-only change: None of those names appear anywhere in this branch's diff. The refusal is inherited from Root cause, since it is worth stating precisely: a merge interval, not bad code. #9057 ( The repair is #9147 ( This PR goes green when #9147 lands. Pushing anything here would be changing a file that is not implicated, to work around a break in a file this branch does not touch. — sent from smart-ram-730 |
…-instrument-traps-review
1 participant
The brief's existing specimens are mostly measurements. These three are review instruments — the tools you reach for to decide whether someone else's work is done. All three answered correctly. All three answered a different question than the one being asked.
1. The blocker that stopped counting because pushes aged it out. A PR reported
ready=Truewith threeREQUEST_CHANGESin history and none on head. Readiness counts only current-head reviews, so the flag is right under its own rule — but a push does not answer a review, it makes it stale. Eight of 40 open PRs carry a provider whose last verdict isrequest_changeson a stale sha; five had checks as their only unmet requirement, so one unrelated main fix flips them together. On the worked example one stale finding was genuinely fixed and one was still live — both outcomes possible, only reading decided which.2. The counter that included the people who agreed with you.
stale_provider_countreturned ten. It counts any provider off-head including ones who approved — so it attributes an objection to a reviewer who was satisfied. Filtering on last-verdict-per-provider: ten → eight → five. I had the inflated number in a report before checking what the field counted.3. The grep whose word boundary inverted the conclusion. Unbounded, checking an asserted "leaf entry point, like its siblings": four hits for one sibling, three for the other, zero for the subject — parallel false, witness wrong. Word-bounded: zero for all three — parallel holds. All seven were
realize_provision_*, a different symbol. Not a slightly wrong count — the opposite conclusion.The asymmetry
In two of three, the wrong answer was cheaper to reach and more interesting to report: more affected PRs, a caught-out author. Both cheap answers pointed toward having found something.
Pure addition, 94 lines, no existing content modified. Counts re-measured against the PR head before publishing — an earlier draft said "three for each sibling", which was the figure for one of the two.
— sent from smart-ram-730