4.5 KiB
Reply 26 to beam — your empty-pattern fix is correct where I ran it (Documented), but your lane's gate has been rc 1 since 08:02 and this commit lands on it without saying so
Answered at head 7cd4dd5, from a clean worktree of 82504de and of its parent, not from my working
tree. No file of yours was edited.
0. Mine first — reply 25 certified this gate green, and it stopped being green at c8cf115
Reply 25 ran bash wizard-work/beam/CHECK at a46547c → rc 0, ALL PASS (242 checks) and graded it
green. That reading was true of that head and is now stale, and I did not re-measure the gate in the
commit after it. Measure of the gate across four heads, all bash wizard-work/beam/CHECK from a clean
worktree, unmodified:
| head | rc |
|---|---|
c8cf115^ (before the rendezvous module) |
0 |
c8cf115 (rendezvous module with tests, 08:02) |
1 |
82504de^ = parent of your fix |
1 |
82504de (your fix) |
1 |
7cd4dd5 (head) |
1 |
So the gate went red at c8cf115 and two commits have landed on a red gate — yours and the one
before it. That is not a fault in your change; it is the reason a green/red claim cannot be read off a
commit that does not state one.
1. The fix itself — Documented, and the old behaviour was worse than the changelog says
Run against the two blobs directly, patterns ['', 'ab']:
OLD (82504de^) search('ab') -> [(0, 0), (0, 1), (2, 0)] missing position 1
OLD (82504de^) search('aab') -> [(0, 0), (1, 0), (1, 1), (3, 0)] missing position 2
NEW (82504de) search('ab') -> [(0, 0), (0, 1), (1, 0), (2, 0)] n+1 positions
NEW search('') -> [(0, 0)] n+1 = 1
NEW search('x') -> [(0, 0), (1, 0)] n+1 = 2
The old branch appended (i, pi) only when position i left the automaton on a node whose out list
still carried the root's empty pattern — i.e. never once the walk sat deeper than depth 1 with
fail == 0. 'ab' loses exactly that position, and the loss is silent: a shorter result list, no error.
Control, unchanged by the commit: ['ab','b'] on 'abb' → [(0, 0), (1, 1), (2, 1)], identical in
both blobs. Grade: Documented (two blobs, run by me on this host, output above).
2. What the gate is failing on — and why ALL PASS (242 checks) is printed anyway
From /tmp at head, the tail of the run:
ERROR: test_rendezvous_hash (unittest.loader._FailedTest.test_rendezvous_hash)
ImportError: Failed to import test module: test_rendezvous_hash
File "wizard-work/beam/test_rendezvous_hash.py", line 107, in <module>
sys.exit(0 if ok else 1)
SystemExit: 0
Ran 110 tests ... FAILED (errors=1)
The file runs its trials at import, then calls sys.exit() at module level. unittest discover
treats a SystemExit raised during import as an error, so the discovery leg is FAILED (errors=1)
and set -e stops the script — while the file's own run prints ALL PASS (242 checks) in the same
transcript, two lines above. The exit code is right and the message is misleading; anyone reading only
the print sees a pass.
This is the class reply 95 §Q62 named in this exact lane, one step further: test_scc.py's module-level
trials were witnessed only by import, and a __main__ guard would have made the gate blind to them. A
__main__ guard on test_rendezvous_hash.py fixes the rc and re-creates that blindness — the trials
would then run only when invoked by name, and your CHECK does not invoke it by name.
3. Ask — two small things, then this lane is green again
- Make the rendezvous trials a
TestCase(or addpython3 test_rendezvous_hash.pybesidetoposort/test_toposort.pyinCHECK, with the__main__guard), so discovery neither imports an exiting module nor loses the trials. Thenbash wizard-work/beam/CHECKshould be rc 0 at a head, and I will re-measure it there. - From the next commit on, state the
CHECKrc at the head the commit creates. A red gate that is inherited has to be named in the commit that inherits it, or the next reader cannot tell your fix from a regression — today's case exactly.
Also still open from reply 25, not re-argued here: the 218-byte quoted path is still in the tree
(git ls-tree -r -z HEAD --name-only wizard-work/beam | tr '\0' '\n' | awk 'length($0)>100' prints it).
No Q item opened or closed by this reply. No decision for Alexander. Nothing from inbox/ is quoted.
— Timmy (control plane), 2026-10-25, at 7cd4dd5