gated-caller: sweeps are 4 not 2, and the truncation line from #552 does not bound the error it claims - #554
Conversation
shipped an hour ago does NOT bound the error it claims to
Two changes, and the first is what refuted the second.
1. THE STUB'S RETURN VALUE DECIDES HOW LONG A CALLER SURVIVES, and so
how much this tool can see. A bare 0 killed suites at the first
`m.f()[0]` or `for x in m.g()`, hiding everything after that point.
Replacing it with an int subclass that also iterates, indexes, sizes
and calls moves the subprocess-sweep count 2 -> 4.
Both new entries verified REAL by reading their suites, not by
trusting the count:
test_estate_provenance.py:26 subprocess.run([executable, tool] + args)
test_pretooluse_guard.py:75 subprocess.run([executable, TOOL, *args])
It subclasses int so everything that worked against the old 0 —
comparison, arithmetic, truthiness — still works.
2. THE TRUNCATION-RISK LINE WAS WRONG AS WRITTEN. It claimed to size the
error: "this is by how much it might". Measured across the stub change
above, it did not move: 28 of 51 before, 28 of 51 after, while two
more real callers became visible.
The suites did not stop failing. They failed LATER, after the calls
that had been invisible. An exit code says a suite ended badly, never
WHERE it ended, so it cannot size what came after. The line now says
the counts are a lower bound of UNKNOWN size, and says explicitly that
this number does not bound it.
That is the third undercount in this figure today: 1 -> 2 -> 4. Each was
published as a count, and each was a property of the stub.
Control: a fixture suite that INDEXES and ITERATES a return value before
its later subprocess run. Under a bare-0 stub it dies at [0] and the
sweep is invisible. Mutation-checked - narrowing the return to 0 fails it.
Measured at b20df2d.
DEV1
|
Warning Review limit reached
Next review available in: 31 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Two changes. The first refuted the second, which I shipped an hour ago in #552.
1. The stub's return value decides how long a caller survives
⛔ A bare
0killed suites at the firstm.f()[0]orfor x in m.g(), so everything after that point was invisible. ⇒ Anintsubclass that also iterates, indexes, sizes and calls moves the subprocess-sweep count 2 → 4.Both new entries verified real by READING their suites, not by trusting the count:
⚠ It subclasses
intdeliberately, so comparison, arithmetic and truthiness against the old0all still work — nothing that passed before stops passing.2. ⛔ The TRUNCATION RISK line does NOT bound the error, and #552 said it did
⇒ ★ The suites did not stop failing. They failed LATER — after the calls that had been invisible. ⛔ An exit code says a suite ended badly, never WHERE it ended, so it cannot size what came after.
⚠ The line now states the counts are a lower bound of unknown size, and says explicitly that this number does not bound it. I would rather ship an unbounded error that says so than a bound that is not one.
⇒ Third undercount in this figure today
★ Each was published as a count. Each was a property of the stub, not of the repository. ⚠ I do not claim 4 is final — it is the number after two rounds of making the probe survive longer, and there is no reason to believe the third round is the last.
⇒ What the gap-finding claim rests on is unchanged: 32 of 36 instruments have no gated caller that runs them as a program.
Control
A fixture suite that indexes and iterates a return value before its later subprocess run. Under a bare-
0stub it dies at[0]and the sweep is invisible. Mutation-checked — narrowing the return value back to0makes it FAIL (swept=[]).Measured at
b20df2d. — DEV1