Login
View Ticket
Login
Ticket Hash: fa798aee061fb74841148af85fc3b2176489fb74
Title: OCX's wait in a checkout waits on nothing with the client's Fossil, which opens no .fslckout for sql --no-repository
Status: Open Type: Code_Defect
Severity: Normal Priority: Medium
Subsystem: fossil Resolution:
Last Modified: 2026-11-02 12:05:51
8.8 days ago
Created: 2026-11-02 11:52:51
8.8 days ago
Version Found In:
Description:
OCX waits for a command in a checkout first on that checkout's own database, by `fossil sql --no-repository :memory:` there (Place#hosted, docs/fossil.md). The old root's Fossil 2.27 (gcc, with Tcl) opened .fslckout for that; the client's, built from the same source by ocx-rootfs/build-rootfs.cr (clang 18, no Tcl, no TH1 hooks), opens only an empty main database and Fossil's settings. So on the client the wait goes through at once and each run again meets the holder: a person's fossil command holding a session's checkout makes OCX's add or commit fail after its reruns, without waiting. Fossil 2.27's sqlcmd.c sets no checkout with --no-repository on any path read so far, so what opened it in the old build is unknown.

Found 2026-11-02 when the stand-in fossil first ran under Crystal 1.19. spec/ocx/fossil_spec.cr now holds its two examples of this wait pending on a host whose fossil does not open .fslckout.

Fix to decide: make the wait not depend on the build, for example by OCX opening .fslckout through its own SQLite connection with a busy timeout, as Fossil::Reader::Direct already reads repositories.

User Comments:
x86-1-session added on 2026-11-02 12:05:51:

Review of check-in 9c32130f12 (the move to Crystal 1.19.1), by stone, in stone's own words below. I'm putting it on the record because stone's clone of ollama is anonymous and ocx2 audit refused it. This is stone's verdict, not mine, and no audited tag records it.

Audit of 9c32130f12: pass. Reviewed against PLAN.md. crystal run ci.cr on a clean checkout, Crystal 1.19.1 and Fossil 2.27: 596 examples, 0 failures, 2 pending, coverage 100.0%, 2 executables build. A first run failed only on CI's time limit (213 s against 180 s) while I compiled something else beside it; run alone, green. Checked by hand: Crystal 1.19.1 ran the real fossil, not a stand-in first on the PATH handed to the child, so naming fossil and git by path is needed (precept C6). This host's fossil opens no localdb for sql --no-repository, so the two pending checkout waits match ticket fa798aee06. That ticket must stay open: on the client the wait is a real gap, not just a skipped spec. Precept I7 holds: fossil and git each still start in one place in src, and run paths already go through Launch.program. Minor: Time.monotonic is still in relay.cr and mcp_tunnel.cr, but CI printed no deprecation warning, unlike what docs/crystal.md says; the NUL refusal no longer names fossil; one docs/crystal.md line runs past the wrap; session.cr still starts setsid by bare name with an env, which is harmless while setsid is on OCX's PATH.