| Comment: | fix(leaf,hub): drop SetMaxOpenConns(1) to unblock concurrent clones (#122)
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 |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk | leaf/v0.0.8 |
| Files: | files | file ages | folders |
| SHA3-256: |
b251b876138e225358c18843b89cd6ca |
| User & Date: | [email protected] on 2026-05-04 19:17:37.000 |
| Other Links: | manifest | tags |
|
2026-05-04
| ||
| 19:24 |
chore: bump leaf v0.0.7 → v0.0.8 (#123)
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). check-in: ca812c4f85 user: [email protected] tags: trunk, v0.0.10 | |
| 19:18 |
chore: bump leaf v0.0.7 → v0.0.8
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 | |
| 19:17 |
fix(leaf,hub): drop SetMaxOpenConns(1) to unblock concurrent clones (#122)
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 | |
| 19:17 |
chore: bump libfossil → v0.5.0 (#121)
* chore: bump libfossil → v0.5.0 * chore: bump libfossil → v0.5.0 in leaf and bridge modules The auto-generated bump-upstream PR only updated the root module's go.mod. The leaf and bridge modules pin libfossil independently and need the bump too — without this, the upcoming #112 cleanup (delete ridToUUID + simplify Agent.Diff using libfossil v0.5.0's UUIDFromRID + whole-checkin Diff) can't land on leaf since leaf's go.mod still resolves to v0.4.5. Worth fixing the bump-upstream workflow separately to walk every go.mod under the repo, but treating that as a follow-up rather than blocking this PR on it. --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Dan Mestas <[email protected]> check-in: c52b0b3b44 user: [email protected] tags: trunk | |