When two openvox-code sync processes run in parallel (e.g. multiple CI jobs), they can corrupt each other's bare clone caches.
Problem:
EnsureClone checks for HEAD, then clones — race between check and clonefetch --prune during another process's git archive can cause failures- No locking mechanism on the cache directory
Proposed solution:
- Use
flock(2) / fcntl file locks on a .lock file per bare clone
- Read lock for
archive, rev-parse, for-each-ref
- Write lock for
clone, fetch
- Consider
golang.org/x/sys/unix for portable file locking
Impact: Data corruption in CI environments with parallel pipelines.
When two
openvox-code syncprocesses run in parallel (e.g. multiple CI jobs), they can corrupt each other's bare clone caches.Problem:
EnsureClonechecks for HEAD, then clones — race between check and clonefetch --pruneduring another process'sgit archivecan cause failuresProposed solution:
flock(2)/fcntlfile locks on a.lockfile per bare clonearchive,rev-parse,for-each-refclone,fetchgolang.org/x/sys/unixfor portable file lockingImpact: Data corruption in CI environments with parallel pipelines.