Fix: suppress idle timeout countdown in provider-wait footer (#3189)

[idling11]

Behaviour changes

Wait duration	Before	After
idle < 60s	waiting for model · 3s	waiting for model
idle ≥ 60s	waiting for model · 60s	waiting for model · 60s
idle ≥ 75% budget	waiting for model · 225s	waiting for model · 225s/300s idle timeout

Fanout / dispatch-pending labels are unchanged and take precedence.

Design decisions

• 60s threshold: long enough that most normal provider think-time completes before the counter appears, short enough that a genuinely stuck stream is flagged.
• 75%-of-budget gate: full Ns/Ms idle timeout only surfaces when the stream is at real risk of timing out.
• Header bar: provider/model names stay there — no need to repeat in every footer stall reason.
• Incident logger: maybe_log_provider_wait_incident keeps full idle/budget detail regardless of footer copy.

Tests (4 passed)

Test	Scenario
provider_wait_reason_fresh_show_only_label	idle < 60s → "waiting for model"
provider_wait_reason_thresholded_show_idle_seconds	idle ≥ 60s → counter appears, no budget
provider_wait_reason_near_timeout_show_full_idle_budget	idle ≥ 75% → full detail
provider_wait_reason_dispatch_pending	pending dispatch label returned

Close #3189.

Summary

Testing

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features
• cargo test --workspace --all-features

Checklist

• Updated docs or comments as needed
• Added or updated tests where relevant
• Verified TUI behavior manually if UI changes
• Harvested/co-authored credit uses a GitHub numeric noreply address

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[gemini-code-assist]

Code Review

This pull request refines the footer UI's model-waiting status by introducing a threshold of 60 seconds before displaying elapsed idle time, and surfacing a detailed timeout warning when the idle time reaches 75% of the stream-idle budget. Unit tests were also added to cover these scenarios. The review feedback points out a potential issue where a configured timeout budget of less than 60 seconds would prevent the near-timeout warning from displaying, and suggests checking the near-timeout condition first to resolve this.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

If a user configures a small stream_chunk_timeout_secs (e.g., less than 60 seconds, such as 30 seconds), the early return if idle < PROVIDER_WAIT_IDLE_SHOW_SECS will prevent the near_timeout warning from ever being displayed, even when the stream is extremely close to timing out (e.g., at 25 seconds of idle time).

Checking near_timeout first ensures that the timeout warning is always surfaced when the stream is at risk, regardless of whether the idle time has crossed the 60-second threshold.

    let near_timeout = budget > 0 && idle >= budget.saturating_mul(3) / 4; // ≥ 75%
    if near_timeout {
        return format!("waiting for model  · {idle}s/{budget}s idle timeout");
    }

    // Normal wait — no countdown noise.
    if idle < PROVIDER_WAIT_IDLE_SHOW_SECS {
        return "waiting for model".to_string();
    }

    format!("waiting for model  · {idle}s")

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[Hmbown]

Thanks @idling11 — I carried this into the v0.8.64 integration branch with your original commits preserved:

• 6e71bad85 fix(tui): suppress idle timeout countdown in provider-wait footer (#3189)
• bda40b157 test(tui): update stall_reason test for #3189 idle threshold

I also added a small review follow-up as 57148e23c so short configured stream-idle budgets still show the near-timeout warning even when elapsed idle time is below the normal 60s display threshold.

Verified on the integration branch with:

• cargo test -p codewhale-tui --bin codewhale-tui --locked provider_wait_reason -- --nocapture
• cargo test -p codewhale-tui --bin codewhale-tui --locked stall_reason_provider_wait -- --nocapture
• cargo fmt --all -- --check
• git diff --check
• python3 scripts/check-coauthor-trailers.py --author-map .github/AUTHOR_MAP --range HEAD~3..HEAD --check-authors

I am keeping this PR open until the integration branch lands and #3189 can be closed against the public mainline.

[Hmbown]

Thank you @idling11 — this landed in the v0.8.64 release branch (thresholded provider-wait footer in crates/tui/src/tui/footer_ui.rs, plus the short-budget test). Tracked via #3189 (now closed as fixed). Appreciated!