Artifact 4c4ec85bcb6cb7240595761a02d01bdb7c25b27eaf21bdf297ee5fbdaddfad58:
- File
internal/sync/horizon_structural.go
-
2026-10-23 05:07:11
— part of check-in
[f8bb98e196]
on branch feat/horizon-cones
— fix(serve): serve reading requests in a read transaction
Every request ran in a write transaction (BEGIN IMMEDIATE) for as long as it was served, a horizon request read the classification memo in another, and each request created the table-sync schema on a repository without it. A clone arriving while another request was served waited for the write lock past the 5s busy timeout and got HTTP 500 "database is locked (SQLITE_BUSY)"; its client gave up after four attempts. The real-repository gate hit it with a horizon clone beside a dense one.
A request none of whose cards can write now runs in a read transaction (db.WithBoundReadTx), which takes a snapshot without the write lock; the memo read does too; loading synced tables only reads, and a schema card creates the schema it registers into. Requests that write keep their write transaction. v0.14.0 has the same write transaction per request: a clone from its server fails the same way while another connection holds the lock. (user: [email protected], size: 12461) [annotate] [blame] [check-ins using]
- 2026-10-23 15:19:13 — part of check-in [ed53ee9c59] on branch feat/horizon-cones — Merge branch 'wip/clone-perf' into feat/horizon-cones (user: [email protected], size: 12461) [annotate] [blame] [check-ins using]
-
2026-10-23 17:16:09
— part of check-in
[ac0bf85d72]
on branch main
— Merge pull request #461 from danmestas/feat/horizon-cones
feat: horizon cones (draft-fossil-horizon-00) (user: [email protected], size: 12461) [annotate] [blame] [check-ins using]
-
2026-10-23 05:07:11
— part of check-in
[f8bb98e196]
on branch feat/horizon-cones
— fix(serve): serve reading requests in a read transaction