crates/perry/tests/ws_client_handle_cross_function_dispatch.rs fails 9 of 11 tests on current main (3411c9d7c8).
cargo test --profile perry-dev -p perry --test ws_client_handle_cross_function_dispatch
test result: FAILED. 2 passed; 9 failed
Failing: helper_wsid_send_dispatches_to_client_runtime, same_named_function_is_not_cross_tagged, transitive_through_polymorphic_intermediate_is_not_tagged, transitively_forwarded_wsid_send_dispatches_to_client_runtime, shadowing_nested_param_does_not_inherit_taint, leading_this_param_keeps_hint_index_aligned, and three others — all at the same assert!(compile.status.success(), ...) on line 49.
Why it isn't caught
Per docs/src/testing/ci-tiers.md, integration suites under crates/*/tests/ run per-PR only when the diff names them (e2e-scoped); the sweep/full tiers' cargo test --workspace is the backstop. So a suite can sit red for a while before anyone touches a file that pulls it in. #9163 is currently open against this file, which is how I noticed.
A caveat on reproducing it — this cost me two wrong readings
My first run showed 11 of 11 failing, and the extra two were an artifact of my own environment. The compiler and the runtime archives had been built from different commits, and perry's coherence guard refuses:
Error: runtime library does not match this Perry compiler:
library build: v0.5.1519 (commit 5f08e77c7cf7)
Perry build: v0.5.1519 (commit 3411c9d7c888)
That refusal surfaces through the test as a bare perry compile failed, which reads exactly like a product bug. Rebuilding -p perry -p perry-runtime-static -p perry-stdlib-static together in one invocation gives the true figure of 9. Anyone triaging this should confirm the coherence line is absent before trusting a count — and note the guard names both commits, which is what makes it diagnosable.
I have not investigated the 9 real failures; the compile output before the assertion shows codegen and "Linking (runtime-only)…" completing, so the failure is after that point.
crates/perry/tests/ws_client_handle_cross_function_dispatch.rsfails 9 of 11 tests on currentmain(3411c9d7c8).Failing:
helper_wsid_send_dispatches_to_client_runtime,same_named_function_is_not_cross_tagged,transitive_through_polymorphic_intermediate_is_not_tagged,transitively_forwarded_wsid_send_dispatches_to_client_runtime,shadowing_nested_param_does_not_inherit_taint,leading_this_param_keeps_hint_index_aligned, and three others — all at the sameassert!(compile.status.success(), ...)on line 49.Why it isn't caught
Per
docs/src/testing/ci-tiers.md, integration suites undercrates/*/tests/run per-PR only when the diff names them (e2e-scoped); the sweep/full tiers'cargo test --workspaceis the backstop. So a suite can sit red for a while before anyone touches a file that pulls it in. #9163 is currently open against this file, which is how I noticed.A caveat on reproducing it — this cost me two wrong readings
My first run showed 11 of 11 failing, and the extra two were an artifact of my own environment. The compiler and the runtime archives had been built from different commits, and perry's coherence guard refuses:
That refusal surfaces through the test as a bare
perry compile failed, which reads exactly like a product bug. Rebuilding-p perry -p perry-runtime-static -p perry-stdlib-statictogether in one invocation gives the true figure of 9. Anyone triaging this should confirm the coherence line is absent before trusting a count — and note the guard names both commits, which is what makes it diagnosable.I have not investigated the 9 real failures; the compile output before the assertion shows codegen and "Linking (runtime-only)…" completing, so the failure is after that point.