Use scoped feature-flag overrides in view_tests instead of global set_enabled

[fbartho]

Closes #13972

Description

view_tests.rs had 22 call sites flipping the process-global FeatureFlag::AgentView/FeatureFlag::CloudMode state via set_enabled(true) with no reset. Under plain cargo test, every test in the warp lib target shares one process, so the flag state leaked into whichever tests ran next — five tests that assume AgentView defaults to false failed whenever they ran after an offender.

This converts all 22 sites to override_enabled(true), the thread-local RAII guard the same module already uses elsewhere; the override reverts on drop at the end of each test. Thread-locality is sufficient: App::test's executor is a single-threaded LocalExecutor, and none of the converted tests spawn OS threads (so no get_overrides()/set_overrides() propagation is needed). Two tests set both flags and bind both guards for the full test body. override_enabled itself is unchanged.

Why CI didn't catch this

CI runs cargo nextest, which isolates each test in its own process — the leak needs a shared-process runner to manifest.

The set_enabled panic guard that should have flagged the misuse (warp_features/src/lib.rs: if cfg!(test) && cfg!(not(feature = "integration_tests")) { panic!(…) }) is dead code by construction: cfg!(test) resolves per-crate at the point it's written, and warp_features is a normal [dependencies] library that's never compiled as a test binary — so the check is unconditionally false for every caller.

Ruled out along the way: feature unification

The issue originally theorized that crates/integration enabling integration_tests defeats the guard via Cargo feature unification. Verified false: warp_core/Cargo.toml's integration_tests feature is [] and never forwards to warp_features/integration_tests, and app doesn't depend on warp_features directly — so that feature can't be reached from a normal app/warp build at all. The guard's deadness is independent of feature flags.

Reproduction

Deterministic single-process repro — a flag-setting test followed by affected tests:

cargo test -p warp --lib -- --test-threads=1 --exact \
  terminal::view::tests::agent_view_lifecycle_updates_input_mode \
  terminal::view::tests::test_insert \
  terminal::view::tests::test_scroll_position_doesnt_change_when_block_finished \
  terminal::view::tests::test_viewport_iter_most_recent_at_bottom

Before: FAILED. 1 passed; 3 failed (assertions like left: "One" / right: "None", scroll-position and viewport-iter panics — matching the issue's reported failures). After: all originally-affected tests plus the flag-setter pass together, ok. 6 passed; 0 failed.

cargo nextest run -p warp -E 'test(view_tests) or test(terminal::view)': 307 passed before and after (process isolation always masked this).

Preventing recurrence

I looked at catching this class mechanically going forward. Verdicts:

Option	Verdict	Why
Clippy disallowed-methods on set_enabled (repo already has .clippy.toml + -D warnings CI)	Not implemented	~74 legitimate call sites (≈26 production, ≈48 crates/integration tests that want real global state) would each need #[allow(clippy::disallowed_methods)] — and every allow looks identical to a reintroduced leak, burying the signal
Repair the cfg!(test) panic guard	Not implemented — maintainer call	Dead by construction (above). A real fix needs a runtime "in test" signal or a test-only-constructible token (≈ re-deriving override_enabled for the global case) — design work, and it inherits the same production/integration scoping problem
Grep-style check in ./script/presubmit	Noted only	Cruder duplicate of disallowed-methods; only worth it if the lint is rejected specifically on annotation-noise grounds

Testing

• cargo test -p warp --lib targeted repro (before/after above)
• cargo nextest run -p warp -E 'test(view_tests) or test(terminal::view)' — 307 passed
• ./script/format --check — clean
• cargo clippy -p warp --lib --tests — zero warnings
• I have manually tested my changes locally with ./script/run
  • Not applicable: the issue only applies to test builds.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

[oz-for-oss]

@fbartho

Every PR must be linked to a same-repo issue before Oz can review it.

This PR is linked to #13972, but no linked issue is marked ready-to-implement yet. Only repository maintainers apply that label, so please wait for a maintainer to mark the issue. Once it is marked, push a new commit or comment /oz-review to re-trigger review.

See the contribution guidelines for the full readiness model.

Powered by Oz

[oz-for-oss]

@fbartho

Every PR must be linked to a same-repo issue before Oz can review it.

This PR is linked to #13972, but no linked issue is marked ready-to-implement yet. Only repository maintainers apply that label, so please wait for a maintainer to mark the issue. Once it is marked, push a new commit or comment /oz-review to re-trigger review.

See the contribution guidelines for the full readiness model.

Powered by Oz