Bug: transient red turn failures should not advance queued messages

[ARCJ137442]

Problem

When Codex ends a turn with a red, non-normal, transient failure message, queue execution semantics break.

Examples include, but are not limited to:

• ■ exceeded retry limit, last status: 429 Too Many Requests
• other transient backend / transport / overload failures that surface as red interruption-style turn endings

Current behavior

• the failed turn is treated like a successfully completed turn
• the next queued unsent message is sent immediately
• the failed current message is not preserved as the active retry unit
• multi-step queued workflows become misordered

Expected behavior

• any transient failure that is rendered as a red, non-normal turn-ending message should not advance the queue as if the previous message completed successfully
• the previously sent current message should remain the active/current message for retry semantics
• queued unsent messages must remain queued and unconsumed
• the next queued message should run only after the previous message truly completes

Goal

Guarantee queue ordering under transient failure conditions so that queued workflows remain sequential and deterministic.

Example

1. send message A
2. A ends with a transient red failure
3. queue still contains message B, C
4. system should retry A or preserve A as the current pending retry unit
5. B must not be sent yet

Scope notes

This issue is intentionally broader than only 429.

Target class:

• transient, retryable, red turn-ending failures

Out of scope:

• normal turn completion
• user-intentional interruption semantics such as explicit cancel/replace flows, unless later found to share the same broken queue-advance path
• permanent hard failures that should not be retried automatically

Acceptance criteria

• a transient red failure does not dequeue or advance later queued messages
• the failed current message is preserved for retry semantics
• queue order after recovery remains A -> B -> C
• add regression coverage for representative transient failure paths

Out of scope for this issue

• preview-color changes from PR fix(tui): align queued preview palette with CI rules #28
• pending-steer recall changes tracked separately in Feature: support Alt+Up recall for pending steer drafts #29

[ARCJ137442]

Implementation start 2026-03-07: issue accepted into active work. Next step is tracing the event path from 429/retry-limit failures to queue advancement so we can pin the correct retry semantics with regression tests.

[ARCJ137442]

Scope expanded on 2026-03-07: this is no longer limited to 429/retry-limit exhaustion. Implementation should cover the broader class of red, non-normal, transient turn-ending failures, while still excluding normal completion and clearly non-retryable hard failures.

[ARCJ137442]

Implementation update on fix/issue-30-queue-retry-ordering:

• Added transient failure classification for queued turn-ending errors, generalized beyond 429 Too Many Requests
• Current retry set includes structured transient failures such as:
  • ResponseTooManyFailedAttempts
  • HttpConnectionFailed
  • ResponseStreamConnectionFailed
  • ResponseStreamDisconnected
  • InternalServerError
  • ServerOverloaded
• Added in-flight / retry tracking so a transient failure retries the current user message before advancing queued messages
• Retry path intentionally skips re-rendering the local user prompt / pending steer to avoid duplicate history cells and duplicate pending-steer entries
• Added regression tests for:
  • retry-limit failure keeps queue order
  • non-429 connection failure keeps queue order
  • transient steer retry does not duplicate pending steers

Local verification completed:

• just fmt
• targeted Bug: transient red turn failures should not advance queued messages #30 regression tests: passed
• cargo test -p codex-tui: passed
• cargo clippy -p codex-tui --tests -- -D warnings: timed out locally on this machine, so final lint confirmation will come from PR CI

[ARCJ137442]

Opened PR #31 to land the generalized transient-failure queue fix. CI is the next gate before producing the next validation exe.

[ARCJ137442]

New manual repro after PR #31: when ■ exceeded retry limit, last status: 429 Too Many Requests appears twice in a row, the next unsent queued message can still be sent afterward. Investigating as a follow-up to the first fix; likely an event-sequence gap rather than a compile/test failure.

[ARCJ137442]

Follow-up fix pushed: block queue advancement during the retry-submission gap (the window after retry submit but before the next TurnStarted). Added regressions for repeated 429 failures and for queue insertion during that gap.

[ARCJ137442]

Follow-up local validation build is ready from commit �73aac776: G:\cargo-target-pr31\debug\codex.exe. Full local cargo test -p codex-tui passed on this patch;
ust-ci was also manually dispatched because GitHub did not auto-enqueue it for the new SHA.