pipeline_python_cross_module_call fails on macos-15-intel (previously masked by the venue-parity harness bug)

[DeusData]

pipeline_python_cross_module_call (tests/test_pipeline.c:6114, assertion at :6154, ASSERT(found)) fails on the macos-15-intel CI leg while passing everywhere else. Filing it for proper attribution rather than leaving it as an ambient red.

Why it only just became visible

It was masked. The macos-15-intel job used to die at Step 0j on a harness defect in tests/test_venue_parity_contract.sh — a printf | grep -q under set -o pipefail, where grep -q exits on match and the writer takes EPIPE, so a satisfied contract reported as violated (fixed in #1879). The job never reached the test phase, so this failure could not be seen.

With that fixed, the same job now runs ~25 minutes further and reports:

pipeline rc=1 pass=254 fail=1 skip=0 secs=48
  FAIL tests/test_pipeline.c:6154: ASSERT(found)
  pipeline_cross_language_same_name_does_not_share_calls_issue725

Evidence so far

what	result
build/c/test-runner pipeline on macOS arm64, clean main 31b611a3	250 passed, 0 failed — the test runs and passes
macos-15-intel (x86_64) in CI	ASSERT(found) fails
Other legs (ubuntu-latest, ubuntu-24.04-arm, macos-14, windows)	no failure of this test observed

Attribution reasoning (not yet concluded)

The harness bug that masked this was intermittent, so macos-15-intel did sometimes get past Step 0j and run the suite. If this test failed deterministically on that leg it should have surfaced long before now. That points at an intermittent failure rather than a straightforward x86_64-vs-arm64 behavioural difference — but that is an inference, not a measurement.

ASSERT(found) on a cross-module CALLS edge is also consistent with the known nondeterministic-resolution-order class (parallel per-file registry work, hash iteration order) rather than a logic error, which would be expected to fail on every platform.

What is queued

A rerun of the failed job on the same SHA, purely as flake measurement — to establish whether the verdict is deterministic on that leg. Per the repo's O9 doctrine a rerun is measurement, never a fix, and a probabilistic pass is not a fixed test.

Next steps

1. Measure: rerun on the same SHA; if it flips, it is nondeterministic and needs a deterministic rebuild (a seam or a held gate), not a budget or cadence tune.
2. If it proves deterministic on x86_64 only, investigate the cross-module resolution path for an architecture-dependent ordering assumption.
3. Either way this needs an at-the-case whitelist entry (WHY + what-was-tried) if it is going to be tolerated red for any length of time — an unexplained red is a board defect, not data.

This is not caused by #1879. That change touches exactly one shell script and cannot affect Python cross-module CALLS resolution; it only stopped hiding this.

[DeusData]

Measured: this is intermittent, not a deterministic x86_64 failure.

Two PRs ran the same test-unix (macos-15-intel, cc, c++, 1/1) job:

PR	result for this leg
#1879	FAILURE — FAIL tests/test_pipeline.c:6154: ASSERT(found), pipeline rc=1 pass=254 fail=1
#1883	SUCCESS

Neither PR can plausibly affect Python cross-module CALLS resolution — #1879 changes a single shell script (tests/test_venue_parity_contract.sh), and #1883 touches the importance-scoring pass. Same leg, same test, opposite outcomes.

That settles the open question from the original report: the inference there was that an intermittent harness bug had been masking this, and that a deterministic failure on this leg would have surfaced long ago. The two samples above confirm it directly, and cost nothing — no rerun was needed.

What this means for the ladder. Per the flaky doctrine (O9), the next step is attribute, not retry:

1. ASSERT(found) on a cross-module CALLS edge is consistent with nondeterministic resolution order — parallel per-file registry work, hash iteration order — rather than a logic error, which would fail on every platform rather than one leg intermittently.
2. If the root cause turns out to be a production race, that is a bug in production code and gets a RED-repro plus a production fix — never a test-side workaround.
3. If it is genuinely a test-side ordering assumption, it needs a deterministic rebuild — a seam, a held gate, or a pinned ordering. Not a budget bump, not a cadence tune, and not a runner retry: a probabilistic pass is never "fixed".
4. Until it is attributed, it needs an at-the-case whitelist entry (WHY + a short what-was-tried report), because an unexplained red is a board defect rather than data.

Still true and worth restating: #1879 did not cause this. It fixed a harness defect that was killing the job at Step 0j before any test ran, which is the only reason this became visible. The masking bug and this flake are independent, and this one is now measured rather than assumed.

[DeusData]

Third sample, and the strongest one: a rerun of the failed job on the SAME SHA passed.

sample	leg	result
#1879, original run	macos-15-intel	FAILURE
#1883	macos-15-intel	SUCCESS
#1879, rerun on the identical commit	macos-15-intel	SUCCESS

Same commit, same job, opposite outcomes. That removes the last alternative explanation — it is not an interaction with either PR's contents, and it is not a deterministic property of the x86_64 leg. The verdict is not a pure function of (code, test, platform), which is the definition this repo gates on.

This does not close the issue. Per the flaky doctrine, a rerun is measurement, never a fix, and a probabilistic pass is not a fixed test. What the three samples establish is only that attribution should proceed down the nondeterminism branch rather than the platform-difference branch:

1. If the root cause is a production race in cross-module resolution, that is a production bug — RED-repro plus a production fix, never a test-side workaround.
2. If it is a test-side ordering assumption, it needs a deterministic rebuild — a seam or pinned ordering. Not a retry, not a budget bump.

ASSERT(found) on a cross-module CALLS edge remains consistent with nondeterministic resolution order (parallel per-file registry work, hash iteration order), which is where I would look first.

Until it is attributed it still needs an at-the-case whitelist entry (WHY plus what-was-tried), since an unexplained red is a board defect rather than data.