The notice builder and the kill loop each hand-computed
`retry_started_ts or call_start` and the "stream open, no progress yet"
predicate. Two copies that must agree or the notice countdown and the
actual kill diverge. `_codex_watchdog_snapshot()` now returns the
attempt origin under the same lock, and `_pre_progress()` is the single
phase predicate for both sites.
Also restores the base preference for `retry_started_ts` over
`last_event_ts` as the non-pre-progress activity anchor. On head a
reconnect marker only coexists with events during pre-progress (retries
reset `last_event_ts`; first progress clears the marker), so the
ordering is behaviour-neutral in production and keeps the existing
`(0.0, 0.0, 1.0)` wait-notice case green.
wait_notice_text and WaitNoticeState.should_emit now both derive near-deadline
from the watchdog tuple, so the two call sites stop recomputing it and passing
it as a kwarg. Two docstrings still described the removed copy as the 60s notice.
Both wait-status builders — the Codex Responses request poller
(chat_completion_nonstream) and the chat-completions stream monitor — rewrote
the status line on every 30s heartbeat once a request had been silent for 60s,
always with "provider may be slow or overloaded" and an unlabeled
"auto-reconnect at Ns". Successful long calls (p95 ~53s on large contexts)
therefore looked unhealthy, and a genuine zero-event stall produced the same
text, so the two states were indistinguishable.
The 30s heartbeat stays (it is gateway liveness) but the visible notice now
comes from one shared, presentation-only module (chat_completion_wait_notice):
- emitted once when the silence crosses the threshold, then only when the wait
phase changes or the applicable watchdog is within 15s of firing;
- neutral phase wording: "waiting for the first provider event" (also
"...after reconnect") vs "provider stream active; Ns without stream events";
stream path: "waiting for the first stream chunk" vs "stream open; Ns
without stream output";
- the reconnect hint names the watchdog (TTFB / stream idle / wall-clock stale
/ stream stale) and the seconds left before it fires, which is unambiguous
across the elapsed-vs-silence timelines the old "at Ns total elapsed" mixed.
No watchdog thresholds or retry behaviour change. The old
_codex_wait_notice_recovery helper (deadline as a bare string) is replaced by
codex_watchdog_deadline (label + seconds remaining). Design ported from the
candidate fix in #92657 (phase-keyed dedupe, labeled deadlines, imminent
window), which targeted a pre-refactor call site that no longer exists.
Fixes#92550
Co-authored-by: chelsealong <chelsealong@126.com>
Squash of the 54 commits on victor-kyriazakos:feat/user-channel-warning-suppression
(PR #112302, head f45c640e55) so the contributor's authorship survives a rebase-merge;
the commits interleave with a cron delivery-ledger rework that the salvage removes in
follow-up commits, so per-commit cherry-picks were not practical.
Adds display.suppress_warning_notifications (global + per-platform, default false):
one resolver (gateway/warning_notifications.py), BasePlatformAdapter.emit_warning /
emit_media_warning / warning_text, a notification_category classification carried
through wakes, queues and persistence, and render/present boundaries for CLI/TUI.
Use request-local stream silence for the waiting notice, preserving quiet
activity heartbeats and all existing watchdog policies. Distinguish a stream
that stopped from a request with no response, and clear this request's notice
on the next poll when events resume. Existing fresh first-event retry phases
also reset the display; recovery deadlines explicitly use total call elapsed.
Add two invariant tests (eight cases), proven red on main, plus EN/ZH docs.
Local SDK SSE through classic CLI callbacks in a PTY verifies active reasoning,
true silence, and an already-visible warning clearing on resumed reasoning.
Related: #92657 addresses repeated waiting notices; its phase deduplication
still labels active streams as no response and is not incorporated here.
