[jdatcmd]

For #1341's "two problems with the runtime filter twins" entry, and #1339's test_join_runtime_filter.py:1 twin_mismatch.

What was wrong

test_join_runtime_filter.py was the twin of native_join_runtime_filter.sh under a different stem, so compare_to_bash never paired them, and #1509 lists the suite as unported. Graded by hand, 16 shell names were missing.

The fix

• Renamed to test_native_join_runtime_filter.py. The stem leaves unported_suites.txt and joins COMPLETE.
• Eleven pytest names said the shell's property in other words ("plan uses the runtime coordinator" for "plan has coordinator", and so on). They now use the shell's words.
• The refusal table builds f"{n} refusal", which meets the shell's $n refusal template. With no literal names left in it, the file leaves the loop-reader list.
• Two premises named their fixture's row count (200 in the shell, 150 in pytest). Both now read "… holds every joined row" and "… holds every dimension key", and each twin still checks its own count. The three shell ledger rows are renamed with their history, and the census doesn't move.
• Ported: "fact-qual plan has coordinator" and "fact-qual conjunction equals heap", the default late-materialization path the shell runs. The twin had only the late-mat-off variant.

Measured

• Parity: compare_to_bash reports 51 literal + 4 template matches, 0 missing.
• Red first: with the runtime bloom check rejecting every odd join key, both twins redden "fact-qual conjunction equals heap" (50 rows, not 100), along with the other answer arms.
• Matrix:
  • shell 63/63 and pytest 16 tests (69 checks) on PG15–19;
  • harness_selftest 1246;
  • collection 750 (cluster_tests 749 → 750);
  • guards 439/439;
  • ledger gate rc 0, orphan scan 0.

It conflicts with #1510 only in expected_tests.txt / TESTS.md / COMPLETE; whichever lands second restates.

🤖 Generated with Claude Code

[OffgridwithJD]

@jdatcmd Approved at f01fac5.

Measured on PG17 and PG18:

• Shell: 63/63 on both.
• Twin: 16 tests, 69/69, on both.
• compare_to_bash: 51 literal + 4 template matches, 0 missing.
• NO_CLUSTER guards: 439/439.
• Ledger gate: rc 0, with the census unchanged at 4388 / 3058 / 1330.
• The three renamed ledger rows: only the name column changes. None of them had ever been red, so there was no history to carry.
• The renamed premises: both still assert their twin's own count (150 in the twin, 200 in the shell), and the new arm's premise asserts 100|150.

Red first: PgColumnarRuntimeBloomMatch returns false for every odd key (source 7929e4e2c66e against head's ba96698e61e3).

• Shell: 9 reds, including fact-qual conjunction equals heap (got 50|280000|280000, want 150|…). The shell as on main gives the same 9, as it should for an arm it already had.
• New twin: reddens that name too (50 against 100).
• Old twin: also caught this mutant, through late-mat-off fact qual equals heap. So the ported arm adds the name the shell has; it doesn't make this mutant newly visible. I found no mutant that separates late-mat on from off, because the filter has no late-mat-specific code.

Not blocking, and already true on main: under this mutant the red sets don't match name for name. The twin doesn't redden scattered answer equals heap, rescan answers equal heap or an empty build on one rescan does not empty the next, because its keys there are all even (80+100g, 90+100g, 40+100g). An odd-key mutant can't reach them. Worth a separate entry: an odd key in each of those fixtures would let the twin see this class.

🤖 Generated with Claude Code