Timeline

Pulls in the SetMaxOpenConns(1) deadlock fix (#120/PR #122) and the libfossil v0.5.0 baseline (PR #121).

This is the version downstream consumers should pin to instead of v0.0.7 (which deterministically deadlocks under concurrent clones). leaf check-in: 89133cefa6 user: [email protected] tags: trunk, chore/bump-leaf-v0.0.8

The applySQLiteTuning helper added in #108 (and propagated to hub/ in #109) capped the libfossil DB connection pool at 1 connection. The intent was to make libfossil's per-connection PRAGMAs stick, but libfossil's clone path has internal goroutines that all need a DB connection — capping the pool deadlocks every concurrent clone, with one goroutine holding the conn while another waits for it.

Bones reported (issue #120) that bumping leaf v0.0.6 → v0.0.7 deterministically deadlocks examples/hub-leaf-e2e/'s 3-leaf concurrent clone test. Reproduced here in hub/clone_concurrency_test.go: 3 parallel libfossil.Clone calls against a shared hub. Without the fix the test hangs until its 25s timeout. With the fix it completes in ~80ms.

Keeping the busy_timeout=30000 PRAGMA — that's the correct primitive for concurrent-write safety; SQLite retries SQLITE_BUSY internally up to the timeout. The pool cap was always overkill.

If we later need PRAGMA stickiness across pooled connections, route it through the modernc driver's per-connection init hook instead of a pool cap.

Closes #120 check-in: b251b87613 user: [email protected] tags: trunk, leaf/v0.0.8