FROSADO / onecloudriver / 31907063039

78%

push

github

fix(fs): harden InitBoltDB lock timeout with clear double-mount message (#75) (#77)

* fix(fs): harden InitBoltDB lock timeout with clear double-mount message (#75)

InitBoltDB opened the metadata store with `bolt.Options{Timeout: 1}`, which
is 1 nanosecond. bbolt's flock loop retries every 50ms and bails out when
elapsed > timeout - 50ms, so the open failed instantly on any contention:
a second mount on the same cache directory, or the brief lock window right
after a crash. The resulting error was an opaque "timeout" with no hint of
the cause.

- cache.go: open with a real 5s lock timeout (boltOpenTimeout) and split
  InitBoltDB into a private initBoltDB(dbPath, timeout) so tests can exercise
  the double-mount path quickly.
- cache.go: detect bolt.ErrTimeout and return a clear, actionable message
  pointing at the double-mount scenario and the --cache-dir workaround.
- cache_boltdb_test.go: regression test asserting the locked path fails with
  the double-mount message (using a short internal timeout).

Verified locally: go build, go vet, golangci-lint (0 issues) and the unit
suite with -race.

🤖 Generated with Codebuff
Co-Authored-By: Codebuff <noreply@codebuff.com>

* docs(fs): update crash-sim flock comment for the 5s boltOpenTimeout

The crash-simulation package comment still described the production
InitBoltDB timeout as 1ns. After issue #75 it is 5s (boltOpenTimeout),
which absorbs the transient ~50ms lock window on its own; the reopen
retry remains only as belt-and-suspenders.

🤖 Generated with Codebuff
Co-Authored-By: Codebuff <noreply@codebuff.com>

* fix(fs): bolt TimeoutError deprecated.

---------

Co-authored-by: Codebuff <noreply@codebuff.com>

7 of 7 new or added lines in 1 file covered. (100.0%)

3785 of 4901 relevant lines covered (77.23%)

501.81 hits per line