## Summary
- add partial SQLite indexes for visible thread lists ordered by
creation or update time
- match the `archived` and non-empty `preview` filters used by
`thread/list`
- add query-plan coverage for both supported sort orders
## Query performance
Benchmarked the production query shape on a snapshot of my database with
~10k threads before and after applying these indexes. The query selected
the full thread projection with `archived = 0`, `preview <> ''`, the
`openai` provider filter, and a page size of 201. Results are the mean
of 30 runs after 5 warmups:
| Query | Before | After | Speedup |
| --- | ---: | ---: | ---: |
| First page, `created_at_ms DESC` | 132.3 ms | 15.1 ms | 8.78x |
| First page, `updated_at_ms DESC` | 123.6 ms | 15.5 ms | 7.99x |
| Cursor page near row 4,000, `created_at_ms DESC` | 51.8 ms | 16.8 ms |
3.07x |
| Cursor page near row 4,000, `updated_at_ms DESC` | 52.4 ms | 17.1 ms |
3.06x |
Before this change, SQLite used `idx_threads_archived`, filtered the
candidate rows, and built a temporary B-tree for the requested ordering.
With the partial indexes, SQLite reads matching visible rows directly in
timestamp order and stops at the page limit. `EXPLAIN QUERY PLAN` no
longer reports `USE TEMP B-TREE FOR ORDER BY`.
The result rows were identical before and after. The two partial indexes
occupy approximately 168 KiB combined on this snapshot.
## Performance under contention
I noticed this issue on a database with high-contention and tried to use
simulated contention to validate the performance in that context.
A synthetic SQLite benchmark ran five concurrent readers, matching the
state database pool size, and fetched 101 rows per query. Results are
the median of three runs on fresh copies of the same database snapshot:
| Query | Before | After |
| --- | ---: | ---: |
| `created_at_ms` mean latency under saturation | 328 ms | 12 ms |
| `created_at_ms` throughput | 16 queries/s | 412 queries/s |
| `updated_at_ms` mean latency under saturation | 336 ms | 14 ms |
| `updated_at_ms` throughput | 15 queries/s | 357 queries/s |
For a burst of 100 queries queued through five connections, p95
completion time fell from 6.90 seconds to 226 ms for `created_at_ms`,
and from 6.31 seconds to 473 ms for `updated_at_ms`.
## Validation
- `just test -p codex-state` (135 tests passed)
- query-plan regression covers created-at and updated-at ordering,
requires the corresponding index, and rejects `TEMP B-TREE`
- `just fmt`
## Summary
- reuse the history-bearing `StoredThread` loaded while probing for a
running thread
- avoid rereading and reparsing the rollout when that probe finds no
active process
- reload after shutting down a loaded thread because shutdown may flush
newer rollout items
- add a regression test that verifies cold resume performs one
history-bearing store read
## Problem
`thread/resume` first reads the persisted thread with history while
checking whether the thread is
already running. When no running process exists, cold resume currently
falls through to
`resume_thread_from_rollout`, which reads and parses the same history
again.
That duplicate work grows with rollout size and remains on the
synchronous resume path even when
the caller requests `excludeTurns`.
## Background
The duplicate read was introduced by #24528, which fixed resume
overrides for idle cached
threads. To support resumes specified by rollout path,
`resume_running_thread` began loading the
stored thread with history so it could resolve the canonical thread ID
and determine whether a
cached `CodexThread` was already loaded.
That history is needed when the loaded-thread path handles the request.
On a cold miss, however,
the function's boolean result could only report that no loaded thread
handled the request. It
discarded the history-bearing `StoredThread`, and the normal cold-resume
path immediately loaded
and parsed the same rollout again.
This change preserves the idle cached-thread behavior from #24528 while
allowing the cold-resume
path to reuse the probe result.
## Performance
I benchmarked real retained rollouts using isolated `CODEX_HOME`
directories, explicit rollout
paths, debug builds of the commit and its exact parent, and alternating
parent/patch order. The
table below uses `thread/resume` with `excludeTurns: true`; response
payload sizes were identical.
| Rollout size | Records | Parent median | Patch median | Median paired
saving |
| ---: | ---: | ---: | ---: | ---: |
| 6 MB | 3,574 | 541 ms | 441 ms | 132 ms |
| 30 MB | 15,220 | 1.505 s | 1.041 s | 701 ms |
| 60 MB | 31,453 | 2.644 s | 1.742 s | 970 ms |
| 149 MB | 100,874 | 10.506 s | 7.156 s | 3.350 s |
| 559 MB | 259,734 | 27.759 s | 16.725 s | 9.836 s |
The absolute saving increases with thread size, as expected when
removing one complete JSONL
history read and parse. Total resume time is also content-dependent, so
the relationship is not
perfectly linear.
I also tested full-history resume with `excludeTurns: false`. The
response payload was
byte-identical between variants, and the same size-dependent improvement
remained visible:
| Rollout size | Parent median | Patch median | Median paired saving |
| ---: | ---: | ---: | ---: |
| 6 MB | 1.052 s | 904 ms | 270 ms |
| 30 MB | 2.667 s | 1.762 s | 924 ms |
| 60 MB | 8.464 s | 6.272 s | 3.680 s |
| 149 MB | 26.719 s | 12.118 s | 14.601 s |
| 559 MB | 40.359 s | 25.475 s | 16.590 s |
## Validation
- `just test -p codex-app-server
cold_thread_resume_reuses_non_local_history_probe`
- `just fix -p codex-app-server -p codex-thread-store`
- `just fmt`
## Summary
- avoid acquiring SQLite's writer slot when the singleton backfill row
already exists
- preserve race-safe repair when the row is missing
- add regressions for writer contention and missing-row repair
## Why
State runtime initialization and backfill-state reads previously
executed
`INSERT ... ON CONFLICT DO NOTHING` even in the steady state. SQLite
still
enters the writer path for that statement, so TUI and app-server startup
could
wait behind another writer for up to the configured five-second busy
timeout.
## Validation
- `just test -p codex-state` (134 tests passed)
- `just fix -p codex-state`
- `just fmt`
## Summary
- skip `opentelemetry_sdk` DEBUG and TRACE events before formatting or
queueing them for the SQLite log sink
- preserve INFO, WARN, and ERROR events from the SDK, along with TRACE
events from application targets
- add a persistence-level regression test for the target and level
policy
## Why
OpenTelemetry's batch log processor emits internal
`BatchLogProcessor.ExportingDueToTimer` meta-events every second per
Codex process. In measured high-fanout `logs_2.sqlite` databases,
low-level `opentelemetry_sdk` events accounted for over 30% of retained
rows (30-60% on the machines of people I asked to check).
Persisting this SDK bookkeeping across many processes adds substantial
write volume and contention without representing application activity.
## Validation
- `just test -p codex-state` (132/132 tests passed, plus bench smoke)
- `just fix -p codex-state`
- `just fmt`
Cargo uses libgit2 by default. In uv, we gave up this entirely and
always call out to the git CLI because it is much more reliable. This is
a part of my attempt to reduce flakes in `rust-ci-full`.
A clean release build takes ~18m and an incremental build takes ~12m.
This is far too slow to iterate on performance related changes and the
build time is dominated by LTO.
This pull request adds a `profiling` profile for Cargo which takes ~13m
clean and ~6m incremental, the primary change is that LTO is disabled.
This matches a profile used in uv and follows the great work at
https://github.com/astral-sh/uv/pull/5955 — there's a bit of commentary
there about the trade-offs this implies.
We've found that this does not inhibit the ability to accurately
benchmark as measurements with LTO disabled are generally consistent
with the results with LTO enabled and it makes it much faster (~2x) to
rebuild after making a change.
This is motivated by my interest in improving Codex TUI performance,
which is blocked by the tragically builds right now.
I tested incremental build times by making a no-op change to the
`codex-cli` crate.
Zanie Blue