Repository navigation
coverage-evidence sandbox never builds fast-mlsirm's compiled Rust extension, failing every test file that imports fast_mlsirm._core directly #1292
Description
Activity
Fresh owner-boundary triage identifies existing canonical central PR #789 (
fix/pyo3-native-peer-gate) rather than a fast-mlsirm leaf change or a competing micro-PR.Why it matches this reproduction:
- feat(coverage): add bounded PyO3 peer-evidence gate #789 classifies only collection failures caused exclusively by an unchanged declared maturin/PyO3 module being unavailable in the source-only sandbox.
- It emits
DEFERRED, not PASS, and requires exact-current-head successfulCI::python,CI::rust, andCI::packageCheckRuns before approval. - fast-mlsirm#951 is still at
286bd2dbba5da8348643b6ad8145967972813ae9; its changed files include Python/product/test/docs paths but no Cargo/native crate, pyproject, lock, workflow, or packaging input. - Its exact-head CI run 32435257997 is successful and contains successful jobs
python,rust, andpackage(plus the versioned Python jobs), so it is a valid operational canary for that bounded peer-evidence design.
However, #789 exact head
861478bb11ba89f71b97dbbdd874b3d872372125has a valid unresolved security review: its deferral marker is written above## Coverage Decision, while the published summary begins at that heading, so the peer-check requirement can disappear and approval can fail open. That head must not integrate or be used as acceptance evidence until the marker survives publication and the exact peer checks are demonstrably enforced.Next causal owner action is therefore to repair #789 test-first, sync it non-destructively to live protected main, regenerate exact-head checks/reviews, then rerun unchanged fast-mlsirm#951. No consumer source workaround or graceful test skip is warranted.
Canonical owner #789 advanced to exact head
31c8d207a5d5cbdde3e0ea98dcd7f50c383b6e4bon protected main0c6b9a6459c9dbdf5e23fb01df7a32a8a14964b3.The reproduced fail-open boundary is repaired: the source-only native deferral marker now survives compact coverage publication, so approval must verify exact-head
CI::python,CI::rust, andCI::package. Focused 140 tests and full 1,513 tests·16 subtests passed locally; all current review threads are resolved. Hosted exact-head checks and a qualifying formal review remain required before integration, followed by a fresh unchanged ContextualWisdomLab/fast-mlsirm#951 canary. This issue remains open until protected-main and downstream operational evidence.Current-main control-plane note from the 2026-08-25 loop:
- feat(coverage): add bounded PyO3 peer-evidence gate #789 remains the existing PyO3 peer-evidence deferral candidate. It can classify a source-only
ModuleNotFoundError: fast_mlsirm._coreas DEFERRED, but it does not run maturin/cargo and therefore does not restore RMSE/recovery ownership tests. - Central
scripts/cistill has no maturin build step. Rust coverage doctoring (docs/doctoring/opencode-rust-coverage-runtime-boundary.md) binds LLVM 19 forcargo llvm-cov, not for a Python extension module. - Do not close this issue when feat(coverage): add bounded PyO3 peer-evidence gate #789 merges. Do not stack a maturin build onto fix(e2e): restrict readiness polling to loopback destinations #1314 (loopback readiness SSRF successor).
Next action: after #1314’s current-head Checks are collected, open a dedicated current-
mainrepair that either builds the declared maturin extension inside the coverage sandbox or fail-closes with an operator message that names the missing_coreartifact and the exact rust-toolchain pin.- feat(coverage): add bounded PyO3 peer-evidence gate #789 remains the existing PyO3 peer-evidence deferral candidate. It can classify a source-only
Current recurrence: fast-mlsirm #1829 at
6374e23fb58a4d00bb7370458dcd78934770e7a9, 2026-09-12.Evidence: https://github.com/ContextualWisdomLab/.github/actions/runs/34695011182/job/103557454131 ; central source
fb17ef556f94f673234aa557254ae52779e9a7b0.The complete log shows 409 Python collection errors importing the unavailable
_core, then cargo-llvm-cov failing to obtainbytemuck: DNS for index.crates.io is unavailable inside the explicitly--network=nonecontainer. Installing maturin alone did not produce the extension. Native product CI at the same PR head is successful (run 34694965705, Python 3.12/3.14, Rust, package); this is alternative behavioral evidence, not measured Rust coverage or formal approval. The docstring advisory also reports 69.8% against 100%; that remains distinct from the failed native setup and requires its own scope assessment.Owner action: inspect the existing sandbox dependency-materialization/build implementation and current writer before patching. Stage hash-verified Cargo dependencies and build the declared extension in the isolated trusted preparation/execution boundary; preserve network isolation. Validate both native import and actual cargo coverage, then rerun the unchanged consumer head. The older source-only deferral candidate cannot establish coverage for this PR because this PR changes Rust sources.
Internal investigation/review deadline: 2026-09-13 KST, chosen because this blocks an active consumer's calibration work. Completion requires successful native collection and actual Rust coverage in the deployed sandbox, followed by an authenticated current-head review. This update does not close the incident or authorize a product/security failure bypass.
Current-head recurrence verified at
6782cdab34015d62a211c8c7a919c486e021e5ad: central OpenCode run34702601784, coverage job103577176721, on 2026-09-12 at 15:41 UTC. Complete raw output again shows 409 collection errors importing_core, GPU collection failure, thenbytemuck/index.crates.ioDNS failures before Rust coverage can execute. Docstring 69.8% is explicitly advisory; it is not the failing coverage gate. Current product CI and Strix103577031062passed separately. No measured coverage or formal OpenCode approval is inferred. This preserves the earlier specimen and adds the actual current-head evidence; the owner repair and deployed downstream acceptance above remain incomplete.Current recurrence from fast-mlsirm #1818: exact head
0f348a47a5643ab840468b41d9d33f73354017ab, coverage run34621596364/ check103336781298. The source-only coverage lane reached the Rust phase but Cargo could not complete its offline dependency resolution, so this remains deferred evidence rather than a coverage pass. No source workaround or skip is proposed.Correction to the recurrence above: the
69.8%figure is Python docstring coverage advisory only. The actual two coverage failures are the configured pytest suite (411 collection errors, exit 2) and the GPU target (no collector plus_coreimport error, exit 4); the coverage decision reports failure count 2. The source-only sandbox could not import the declaredfast_mlsirm._coreextension. No source-backed failure in the changed 45-line generation overflow acceptance test was identified.The Noema artifact still contains only preflight/sidecar provider failures and no actual review payload. The fallback
APPROVEtext in the OpenCode log therefore does not establish a qualifying real-model approval or formal current-head receipt. This remains an infrastructure/materialization and review-evidence recurrence under #1292, without dismissing any unverified confirmed finding.
Problem
The central
coverage-evidencejob (OpenCode Review Dispatchworkflow, "Measure test and docstring evidence" step) failsfast-mlsirm#951at current head286bd2dbba5da8348643b6ad8145967972813ae9withCoverage Decision: FAIL, Failure count: 2— but neither failure reflects a real problem in the PR's diff.Evidence
Run: https://github.com/ContextualWisdomLab/.github/actions/runs/32620501327/job/97147899712
Failure 1 — 11 test files fail to collect:
(same for test_cat_selection_rust_ownership.py, test_cov_f_fit.py, test_inference_nonfinite_uncertainty.py, test_inference_rust_vcov_ownership.py, test_linking_fixed_anchor_rust_ownership.py, test_observed_information_rust_ownership.py, test_observed_information_work_budget.py, test_rt_rust_max_iter_backstop.py, test_test_form_rust_ownership.py, test_validation_policy_contract.py)
I confirmed these same unguarded
import fast_mlsirm._core as coremodule-level imports already exist onmaintoday (e.g.tests/test_cat_rust_ownership.py), not introduced by PR #951 — so this isn't the PR's doing. fast-mlsirm is Rust-first by design (ARCHITECTURE.md/CLAUDE.md: "the Rust core is the primary numeric path," built via maturin asfast_mlsirm._core), and these specific test files are the fail-first ownership contracts that require the compiled core to exist — a graceful skip isn't appropriate for them (that would silently hide a rust-ownership regression). Thecoverage-evidencesandbox apparently never builds this extension (the log shows no maturin/cargo build step at all, onlypip-level Python toolchain checks), so any PR touching these paths — or possibly any fast-mlsirm PR at all, since these files are unconditionally collected — hits 11 fatal collection errors before a single test in the affected files can run.Failure 2 — GPU parity test:
Likely downstream of the same missing-
_coreproblem (or a stale/renamed test id) — not independently investigated.Likely same root cause as a known issue
This looks like the same class of gap as #591 ("fix(review): update offline Rust coverage toolchain" — the trusted offline coverage image's baked-in Rust toolchain was too old to build a target crate for
codec-carver, silently failing the compiled-extension step before any test ran).fast-mlsirmpinsrust-toolchain.tomltochannel = "1.97.1"; I did not confirm whether the coverage sandbox even attempts a Rust/maturin build for fast-mlsirm (no such step appears in this job's log at all, unlike #591's evidence which shows an explicit failing Rust step) — that distinction matters for whoever fixes this: either the build step is missing entirely for this repo's pyproject/maturin shape, or it runs and fails silently upstream of what I could see in the tail of the log.Impact
Blocks OpenCode approval (
REQUEST_CHANGESposted regardless of actual PR content) for any fast-mlsirm PR whose coverage-evidence run collects the fulltests/directory — i.e. potentially most/all of them, independent of the PR's own changes.Not attempting a fix
Same reasoning as #1250 and #591: the coverage sandbox's build/install pipeline is intentionally hardened (offline, tokenless, hash-pinned) and I don't have visibility into how it provisions the Rust/maturin toolchain or whether that's even attempted for this repo's
pyproject.toml(maturinbuild-backend). Recording reproducible evidence for whoever owns that provisioning step rather than guessing at a fix.Related
Agent: Claude