Summary
workflows::ops_install::install_fetch_tests::non_2xx_install_fetch_returns_err_for_4xx_and_5xx fails intermittently in the full-suite Rust coverage run with url scheme http not allowed; https only, even though it sets OPENHUMAN_SKILL_INSTALL_ALLOW_LOCAL_HTTP=1. It passed on a plain re-run — a process-global env-var race under parallel test execution.
Problem
Observed while a TinyAgents port PR (#4539) temporarily ran the full coverage suite (a Cargo.toml/Cargo.lock change triggers the config-level full fallback; normal PRs run domain-scoped and don't hit it).
- What happens: the test locks
TEST_ENV_LOCK, std::env::set_var(ALLOW_LOCAL_HTTP_ENV, "1"), then calls install_workflow_from_url_with_home on a loopback http:// mock. Intermittently allow_local_http_install_url reads the env as unset and validate_install_url (src/openhuman/workflows/ops_install.rs:717) rejects the scheme.
- Expected: with the escape-hatch env set, the loopback URL passes validation and the test asserts the non-2xx status is surfaced.
- Impact: flaky red on any full-suite run; does not reproduce in isolation.
- Cause:
std::env::set_var is process-global and racy across threads; TEST_ENV_LOCK only serializes tests that take the lock, so a concurrently-running env-reading/writing test can observe a stale value.
Repro (flaky): run the full lib test suite in parallel (cargo test -p openhuman / cargo llvm-cov -p openhuman), not the single test.
Solution (optional)
Remove the process-global env dependency from the hot path — e.g. thread an explicit "allow local http" flag through InstallWorkflowFromUrlParams / a config value for tests instead of reading std::env at validation time, or ensure every env-touching test in the crate shares TEST_ENV_LOCK.
Acceptance criteria
Related
Summary
workflows::ops_install::install_fetch_tests::non_2xx_install_fetch_returns_err_for_4xx_and_5xxfails intermittently in the full-suite Rust coverage run withurl scheme http not allowed; https only, even though it setsOPENHUMAN_SKILL_INSTALL_ALLOW_LOCAL_HTTP=1. It passed on a plain re-run — a process-global env-var race under parallel test execution.Problem
Observed while a TinyAgents port PR (#4539) temporarily ran the full coverage suite (a
Cargo.toml/Cargo.lockchange triggers the config-level full fallback; normal PRs run domain-scoped and don't hit it).TEST_ENV_LOCK,std::env::set_var(ALLOW_LOCAL_HTTP_ENV, "1"), then callsinstall_workflow_from_url_with_homeon a loopbackhttp://mock. Intermittentlyallow_local_http_install_urlreads the env as unset andvalidate_install_url(src/openhuman/workflows/ops_install.rs:717) rejects the scheme.std::env::set_varis process-global and racy across threads;TEST_ENV_LOCKonly serializes tests that take the lock, so a concurrently-running env-reading/writing test can observe a stale value.Repro (flaky): run the full lib test suite in parallel (
cargo test -p openhuman/cargo llvm-cov -p openhuman), not the single test.Solution (optional)
Remove the process-global env dependency from the hot path — e.g. thread an explicit "allow local http" flag through
InstallWorkflowFromUrlParams/ a config value for tests instead of readingstd::envat validation time, or ensure every env-touching test in the crate sharesTEST_ENV_LOCK.Acceptance criteria
set_varfor the local-http escape hatch on the tested pathRelated
src/openhuman/workflows/ops_install.rs)