jif-oai 2c5eeb6b1f fix: flaky test (#11428) ...

stage1_concurrent_claims_respect_running_cap was flaky due to SQLite
lock contention, not cap logic correctness. The claim flow used deferred
transactions (BEGIN) with read-then-write behavior, which can fail under
concurrency with SQLITE_BUSY_SNAPSHOT/database is locked when upgrading
a read transaction to a write transaction. We fixed this by using BEGIN
IMMEDIATE for stage1 and phase2 claim paths, so lock acquisition happens
up front and contenders serialize cleanly instead of failing during
upgrade. After the change, codex-state tests pass and stress reruns of
the flaky path no longer reproduced the failure.

2c5eeb6b1f · 2026-02-11 10:23:18 +00:00

History

..

migrations

feat: mem v2 - PR5 (#11372)

2026-02-10 23:22:55 +00:00

src

fix: flaky test (#11428)

2026-02-11 10:23:18 +00:00

BUILD.bazel

feat: sqlite 1 (#10004)

2026-01-28 15:29:14 +01:00

Cargo.toml

feat: drop sqlx logging (#10398)

2026-02-02 19:26:58 +00:00