docs: record the Database busy flake as R26, and correct what the timeout fix achieved

The busy_timeout raise in the previous commit did not stop the intermittent
failure. Run 35889922107 failed on the very commit that raised it, while the
pull-request run on the same commit passed, so it is seed- and load-dependent
and the raise treated the wrong mechanism.

Why no timeout can fix it: SQLite returns SQLITE_BUSY immediately, without
consulting the busy handler, when a connection holding a read transaction tries
to upgrade to a write while another connection holds the write lock, because
waiting there could deadlock.

R26 records it with what provokes it (two connections, and fifty concurrent
writers queued on purpose at slice 070 AC7), what has been ruled out, three
candidate fixes not yet taken, an owner, and a lift condition a stranger can
check: ten consecutive green runs of the full suite with the stress test still
in the default run. The raise is kept because it helps ordinary lock waiting,
and is no longer described as the fix for this.

Signed-off-by: Ayla Croft <aylacroft@proton.me>

Author: HackTuah

config/test.exs

@@ -143,6 +143,14 @@ else
   # test lost. The shipped value is unchanged and is still guarded by
   # test/trinity/repo_config_test.exs, which reads it from the file rather than from this
   # override.
+  #
+  # Measured afterwards and recorded here rather than left implied: raising this did **not** stop
+  # the intermittent failure (run 35889922107 failed on the very commit that raised it, while the
+  # pull-request run on the same commit passed). SQLite returns SQLITE_BUSY immediately, without
+  # consulting the busy handler, when a connection holding a read transaction tries to upgrade to
+  # a write while another connection holds the write lock, because waiting there could deadlock.
+  # No timeout affects that path. The raise is kept because it does help ordinary lock waiting,
+  # but it is not the fix for what is recorded as R26 in docs/06-risk-register.md.
   config :trinity, Trinity.Repo,
     database: Path.expand("../trinity_test.db", __DIR__),
     pool: Ecto.Adapters.SQL.Sandbox,

docs/06-risk-register.md

@@ -25,3 +25,4 @@
 | R24 | Fired 2026-09-20, in slice 013: neither precompiled `mdex_native` artifact loads in Burrito's musl ERTS (both need glibc's `libgcc_s`; `_dl_find_object: symbol not found`). Lifted the same day by the owner's decision: the linux package builds the NIF from source for musl with Zig as the linker (`scripts/zig-cc-musl`, config/config.exs, `rustler` at build time), measured on a fresh install of the packaged binary rendering the real provider's answer; the `--smoke` path now prints `TRINITY_SMOKE_MARKDOWN=ok` and exits 3 otherwise, and the `package` workflow reads that line on every target, so a dead NIF cannot pass again. Residual: macOS and Windows use the precompiled artifact, and the `package` workflow has yet to run green there since the slice/011 tag (an older failure at "Serves HTTP 200", now diagnosed by the step's log). The row above stands as written | none | none | none | none | 013 |
 | R23 | EMA / ID-JAG is beta everywhere (vendors label it so); IETF draft still moving | Low (re-scoped 2026-09-22) | Med | Spec revision breaks the exchange at the external authorization server, which is where it happens: Trinity redeems no assertion since the owner's decision of 2026-09-22 (slice 062 NOTES) | The resource server validates whatever audience-bound token that server issues, so a draft revision is that server's upgrade, not Trinity's; the row stays until the deferral lifts | 062 |
 | R25 | `glib` 0.18.5 carries GHSA-wrw7-89jp-8q8g (medium, unsoundness in `Iterator` and `DoubleEndedIterator` impls); first patched in 0.20.0 | Low | Med | The advisory is open against `src-tauri/Cargo.lock`; measured 2026-09-23 | It is transitive through the GTK 0.18 stack (`gtk` 0.18.2, `webkit2gtk` 2.0.2) that Tauri 2.11.5 requires on Linux, so it is fixed by a Tauri release built on gtk-rs 0.20 and not by a direct bump. **Scope:** the desktop shell only. The `headless` release is `steps: [:assemble]` with no Burrito and no `src-tauri`, so a server deployment does not ship this dependency. Owner: the maintainer. Lift condition: a Tauri release whose Linux stack resolves `glib` >= 0.20, adopted by the desktop shell work | 100 |
+| R26 | An intermittent `Exqlite.Error: Database busy` fails the test suite on loaded CI runners, in a different test each time, always on a write to the main repository | Med | Low (test-only; no production path) | Failed the gate on pull requests 67, 70 and again on the commit that attempted to fix it; the same commit passed on its other run, so it is seed- and load-dependent. Not once reproduced locally across repeated runs | Ruled out: `busy_timeout`, raised from the shipped 5 s to 30 s in the suite, did not stop it. SQLite returns BUSY immediately, without the busy handler, when a read transaction upgrades to a write while another connection holds the write lock; no timeout affects that path. The suite runs two connections (one for the sandbox owner, one for Oban's boot check) and deliberately queues fifty concurrent writers at slice 070 AC7, which is the load that provokes it. Candidate fixes, not yet taken: drain the stress test's sessions before the suite continues; give that test its own tag and CI step; or remove the second connection's need. Owner: the maintainer. Lift condition: ten consecutive green CI runs of the full suite with the stress test in the default run | 070 |