[Bug] Competing paginated rollout writers emit overlapping ordinal sequences

Summary

Paginated rollout JSONL can receive overlapping ordinal sequences from competing/stale writer state. A single duplicate or backward ordinal then permanently wedges thread_history_projection_state, leaving the UI on an old snapshot while the canonical transcript continues growing.

This is broader than a one-off corrupted cursor: multiple active threads can become affected simultaneously, and one rollout can contain several independent ordinal regressions.

Related symptom report: #41079.

Environment

• Codex Desktop on Windows 11 x64
• Paginated thread history
• Observed with a current bundled alpha runtime

Sanitized fleet evidence

• All SQLite databases passed PRAGMA quick_check, foreign_key_check, and migration checks.
• Four live threads were wedged concurrently.
• Logs contained more than 1,200 repeated failed to project durable rollout warnings.
• Ten non-monotonic ordinal transitions were found across the 43 rollouts represented in thread_history_projection_state.
• One affected rollout contained three separate regressions, so advancing the SQLite cursor past only the first duplicate would fail again later.

Producer pattern

A representative sequence was:

ordinal N:   event_msg/token_count
ordinal N+1: event_msg/token_count
ordinal N:   event_msg/thread_settings_applied
ordinal N+1: event_msg/thread_goal_updated
ordinal N+2: event_msg/task_started
ordinal N+3: later durable history continues normally

This looks like two append paths assigning ordinals from independently cached tail state. The newer turn starts from stale N even though another writer has already persisted N and N+1.

Projection failure

read_projection_steps currently treats every ordinal < next_ordinal as fatal. Consequently, even stale records that produce no projected turns/items permanently block all later valid history:

thread history projection expected ordinal N+2, got N

The durable rollout remains complete and parseable. The SQLite view simply stops advancing.

Expected behavior

1. All writes to one rollout must share one serialized ordinal allocator, or refresh and lock the durable tail before assigning ordinals.
2. A stale decoded record that is provably a thread-history no-op must not permanently wedge projection.
3. Meaningful duplicate or out-of-order records must still fail closed or trigger a safe rebuild rather than being silently discarded.
4. Projection failure should be surfaced in the UI and have an automatic repair path.

Tested defensive patch

Patch and regression test:

https://github.com/TryDotAtwo/codex/commit/c148c15fb7e75cd76865f75d813cb249cde40f6c

The patch skips a stale ordinal only when:

• the line decoded successfully;
• no rejected lines precede it;
• project_rollout_line produces no changed turns or items;
• it is not a projected realtime item.

Meaningful duplicate ordinals remain rejected by the existing test.

Verification:

cargo test -p codex-thread-store
235 passed; 0 failed

The regression test was verified red before the implementation (expected ordinal 2, got 1) and green afterward.

Privacy

No thread identifiers, prompts, absolute paths, credentials, raw logs, or user content are included.

Start in the codex-thread-store package by reading read_projection_steps and project_rollout_line, then run the package tests. Use the documented regression scenario to distinguish stale no-op records from meaningful duplicate or out-of-order records. Done means projection no longer wedges on provably harmless stale records while meaningful ordinal failures remain rejected and the regression test passes.