71 module-gated tests never run in CI; 10 of them fail on a split store (test-side, no product defect)

[M3gA-Mind]

Problem

71 module-dependent tests are permanently ignored, and the environment variable their ignore messages tell you to set is read by nothing. Meanwhile CI already downloads the modules those tests need, on every run, and executes exactly one of them.

OPENHUMAN_MODULE_PATH
  read as an env var (var()/var_os()) anywhere in src/ or tests/ :  0
  named in #[ignore = "..."] messages                            : 71
  set by any workflow in .github/workflows/                      :  0

total #[ignore] tests in the repo                                : 134   (71 = 53% of them)

OPENHUMAN_MODULE_PATH exists only as ignore-message text. Nothing consults it. Setting it does nothing.

Representative gates:

// src/openhuman/memory/read_rpc_tests.rs:631, :666, :732
#[ignore = "needs a built tinymemory module (OPENHUMAN_MODULE_PATH) and …"]

// src/openhuman/tools/impl/system/tool_stats.rs:191, :217
#[ignore = "needs a built tinymemory module (OPENHUMAN_MODULE_PATH) …"]

// src/openhuman/tools/impl/document/tests.rs:163
// src/openhuman/tools/impl/presentation/tests.rs:149, :231
#[ignore = "needs a built tinydocs module (OPENHUMAN_MODULE_PATH) …"]

The modules are already there

ci-lite.yml (job rust-core-coverage:, line 671) downloads and verifies both artifacts, then exports:

# .github/workflows/ci-lite.yml:774-777
echo "TINYMEMORY_TEST_MODULE=$memory_dir/libtinymemory_module.so" >> "$GITHUB_ENV"
echo "TINYJUICE_TEST_MODULE=$juice_dir/libtinyjuice_module.so"   >> "$GITHUB_ENV"

And the host does honour that one:

// src/openhuman/memory/binding.rs:389
if let Some(path) = std::env::var_os("TINYMEMORY_TEST_MODULE") {
    config.modules.overrides.push(...)

TINYMEMORY_TEST_MODULE is set by five workflow sites (ci-full, ci-lite, e2e-reusable ×2, test-reusable) and read in 7 places in src/. It is the real variable.

So the cost of running these tests — downloading, checksumming and unpacking the module artifacts — is already paid on every CI run. What is missing is the tests being allowed to use it.

What actually runs today

Exactly one ignored test, by name:

# .github/workflows/ci-lite.yml:779-784
- name: Run TinyJuice host-module regression
  run: |
    cargo test --lib --features modules \
      openhuman::agent::tinyagents::middleware::tests::tool_output_tabulates_a_large_graph_for_a_non_exempt_tool \
      -- --ignored --exact

--exact with a single path. The other ~70 never execute, in any lane.

Why this matters now

Today produced five separate incidents of a test drifting from the code it covers and merging green — #5776, #5797, #5818, a vacuous test caught by CodeRabbit on #5812, and a list_chunks_rpc test that had been broken since 5828ad9d2 (2026-08-26 10:09) and only surfaced when the changed-modules-scoped lane happened to select it.

Tests that never run cannot catch any of that. Worse, they read as coverage: the file contains a test named for the behaviour, so the next person reasonably assumes the path is protected. The most recent case is precisely a module-dependent read path — the class this ignored population covers.

There is also a documentation defect independent of the wiring: an ignore message that names a variable nothing reads sends anyone trying to run these tests locally down a dead end. That is how the premise "the coverage lane has no module" was reached during today's investigation — the lane has one, under a different name.

Suggested direction

Deliberately not prescriptive about the mechanism, but the requirement is that these tests either run or honestly declare they cannot:

1. Decide what the gate should be. Either make the ignore conditional on TINYMEMORY_TEST_MODULE / TINYJUICE_TEST_MODULE (the variables that exist), or introduce a real OPENHUMAN_MODULE_PATH and set it in CI. Do not leave a third name.
2. Run them where a module is present. rust-core-coverage already has both modules in scope. Adding the module-gated set there is close to free, since the download already happens.
3. Fix the 71 ignore messages so they name a variable that works.
4. Report the count. If some genuinely cannot run in CI, log how many were skipped and why. A silent skip is indistinguishable from a pass — the failure mode this whole issue is about.

Worth checking as part of the same pass: how many of the 71 still compile and pass at all. Some may have drifted exactly like the five above, in which case turning them on will surface real breakage — that is the point, but it should be expected rather than a surprise.

Notes

Found while diagnosing a red main (the memory_core_threads_raw_coverage_e2e failure). Related: #5820 (a real failure demoted below the threshold anyone watches) — same theme, different layer.

[M3gA-Mind]

Correction from the filer — two claims in this issue are wrong

1. OPENHUMAN_MODULE_PATH is not dead. It works.

The issue title and body say it is "read by nothing". That is incorrect, and it came from a measurement scoped to src/ and tests/ only — the implementation lives in a vendored crate:

vendor/tinybus/crates/tinybus/src/module/host.rs:587
    let mut paths = std::env::var_os("OPENHUMAN_MODULE_PATH")   // PATH-style, via split_paths

So the 71 #[ignore] messages name a real, working variable. There are two mechanisms, with different shapes and different precedence:

variable	shape	resolution order
TINYMEMORY_TEST_MODULE	a file path → modules.overrides	checked first (modules/ops.rs:121, wired at memory/binding.rs:389)
OPENHUMAN_MODULE_PATH	a directory list → tinybus search path	checked third (modules/ops.rs:132)

ops.rs says so in its own comment: "The search path tinybus itself honours, including OPENHUMAN_MODULE_PATH." So "settle the naming" is a choice between two real names, not the removal of a fake one.

2. There is no product defect behind the failures.

The issue speculated the 10 failures might be a real round-trip bug. They are not. Measured on 7e52f3bf3 with the pin at 1.13.2, freshly rebuilt, module digest verified, and the run proven non-vacuous by triangulation (real module → PASS 2.44s; bogus path → FAIL 0.18s; no env var → PASS 10.13s):

0 of 10 pass, and the panic messages are byte-identical to the 1.12.0 run — same place, same text. Nothing in #5823/#5825/#5812 touched these paths.

The cause is a split store in the tests: they write through one route and read back through another, and the two are different directories.

test	writes via	reads back via	result
store_core	tool → bound driver	active_memory_guard() — same driver	PASS
flows::memory_tools ×5	tool → bound driver	UnifiedMemory::new(tmp.path(), NoopEmbedding, None) (memory_tools.rs:601) — a fresh in-process engine over an unrelated tempdir	FAIL
read_rpc ×3	ingest_chat(cfg, …)	list_chunks_rpc(cfg, …) with workspace_dir = a fresh TempDir (read_rpc_tests.rs:14-17)	FAIL

The module captures one workspace per process, and binding.rs:380-388 pins every test binding to the process-global shared_memory_test_workspace(). The driver writes to the shared workspace; the test reads its own tempdir. The read can never find the write.

Two are different again:

• execute_rejects_invalid_kind_after_validation — not a store split. It asserts an error string the port deliberately removed, and the doc comment directly above it (search_entities.rs:186-189) already says so: "a weaker guarantee than the pure-function check it replaced, so it is called out rather than quietly relaxed." Stale by design, never re-anchored.
• process_channel_message_uses_autosaved_memory_after_history_is_cleared — additionally needs ranked recall, which NoopEmbedding cannot provide.

What this issue actually is, then

Smaller than filed in one way, larger in another:

• No product bug to chase. The engine is fine.
• But not a one-line gate change either. Ten tests need re-anchoring onto a single route — read back through the bound driver, as store_core already does. Bounded, mechanical, provable.
• The wiring half stands unchanged: these tests still never run in CI, while the lane already downloads the module.

Apologies for the two wrong claims; they should not be carried forward by anyone picking this up.