jcode-tui test isolation: with_temp_jcode_home does not clear JCODE_NAMED_PROVIDER_PROFILE, so 6 tests fail when run from inside a Jcode session

Closed Beginner friendly
  • Is something wrong?
#2,076 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
testing

Research direction

Read crates/jcode-tui/src/tui/app/auth_tests.rs and inspect the with_temp_jcode_home helper’s saved_env list, comparing it with the sandbox helpers named in crates/jcode-base. Add the named profile variable to the test environment cleanup, and consider the two OpenRouter variables mentioned in the issue. Run the reproduction command from the issue with a named profile set; done means all 3380 tests pass without the profile leaking into the suite.

Written by the indexing model from the issue text.

Description

Description

jcode-tui's test helper with_temp_jcode_home saves and clears eight JCODE_OPENAI_COMPAT_* / OPENAI_COMPAT_API_KEY vars, but not JCODE_NAMED_PROVIDER_PROFILE. When the suite runs from inside a Jcode session that has a named provider profile configured, that var is inherited and six jcode-tui tests fail with misleading provider errors.

This is a test-isolation gap, not a product bug. CI never sets the var, so CI is unaffected. It specifically bites self-dev agents and anyone running the suite from inside a session, which is the normal way to work on this repo.

Reproduction

$ echo "$JCODE_NAMED_PROVIDER_PROFILE"
easycli

$ COLORTERM=truecolor cargo test -p jcode-tui --lib -- --test-threads=1 \
    --skip test_prompt_entry_shimmer_color_moves_across_positions \
    --skip right_fact_stack_uses_neutral_gray_except_for_context_usage
test result: FAILED. 3374 passed; 6 failed; 32 ignored; 0 measured; 1 filtered out

$ env -u JCODE_NAMED_PROVIDER_PROFILE -u JCODE_RUNTIME_PROVIDER -u JCODE_ACTIVE_PROVIDER \
    COLORTERM=truecolor cargo test -p jcode-tui --lib -- --test-threads=1 \
    --skip test_prompt_entry_shimmer_color_moves_across_positions \
    --skip right_fact_stack_uses_neutral_gray_except_for_context_usage
test result: ok. 3380 passed; 0 failed; 32 ignored; 0 measured; 1 filtered out

The six affected tests, all of which also pass individually once the var is cleared:

tui::app::auth::tests::tui_openai_compatible_key_save_persists_key_for_current_session
tui::app::auth::tests::tui_openai_compatible_local_key_save_allows_empty_key
tui::app::tests::test_account_local_shared_daemon_retains_inventory_center_and_saved_defaults
tui::app::tests::test_model_picker_remote_comtegra_model_uses_comtegra_route_not_copilot
tui::app::tests::test_remote_current_fpt_live_model_uses_fpt_route_not_copilot_without_cache
tui::app::tests::test_side_panel_visibility_change_resets_diagram_fit_context

Mechanism

openai_compatible_profile_is_configured consults active_named_provider_profile_is_configured before the built-in profile checks, and that returns Some(..) as soon as JCODE_NAMED_PROVIDER_PROFILE is non-empty:

// crates/jcode-base/src/provider_catalog.rs:1238
let _profile_name = std::env::var("JCODE_NAMED_PROVIDER_PROFILE")
    .ok()
    .map(|v| v.trim().to_string())
    .filter(|v| !v.is_empty())?;

Short-circuiting on an active named profile is correct and deliberate (#402). The bug is only that the jcode-tui helper does not neutralise the var for tests that assert on built-in profile state, so:

  • auth_tests.rs:105 and auth_tests.rs:221 fail their openai_compatible_profile_is_configured assertions
  • the Comtegra and fpt routing tests resolve to Copilot instead of their own routes, e.g. glm route should be Comtegra/api key, got: [PickerOption { provider: "Copilot", ... }]

jcode-base already gets this right, which is good precedent for the fix:

  • crates/jcode-base/src/auth/test_sandbox.rs:128
  • crates/jcode-base/src/provider/tests.rs:48
  • crates/jcode-base/src/auth/tests.rs:543

Suggested fix

Add JCODE_NAMED_PROVIDER_PROFILE to the saved_env list in with_temp_jcode_home (crates/jcode-tui/src/tui/app/auth_tests.rs:9), matching the jcode-base sandboxes. Worth auditing the sibling JCODE_OPENROUTER_API_KEY_NAME and JCODE_OPENROUTER_ENV_FILE vars at the same time, since active_named_provider_profile_credential_source reads both and neither is cleared either.

A deeper option, if the maintainers prefer it: have the tui tests reuse the jcode-base sandbox helper rather than maintaining a second hand-rolled allowlist, so this class of gap cannot reappear per-crate. Related: #596.

Context

Found while verifying #1342. I initially mis-reported these six as upstream product failures in this comment and corrected it here; the environment, not the code, was at fault. Filing the real finding separately so it is not lost.

Verified on af08cc62c (v0.99.716-dev, origin/master plus three unrelated local fixes), Linux, with a TTY.

Dominant language
Rust
Stars
19.9k
Forks
2.3k
Avg merge
2d 9h
Merged PRs (30d)
12

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from 1jehuang/jcode

All issues in 1jehuang/jcode

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.