datatug / datatug-core / 34393684711

100%

push

github

fix(filestore): remove the data race in loadSchemaModel fan-out (#314)

loadSchemaModel spawned two parallel.Run closures that both wrote directly
to the shared schemaModel.Tables field (one for "tables", one for
"views"). Besides being a data race (WARNING: DATA RACE at
loader_internals.go:152/156), this silently dropped whichever half
finished first: the last writer's result clobbered the other's, so a
loaded schema was nondeterministically missing its tables or its views.
Fixed by giving each goroutine its own local slice and merging them after
parallel.Run returns.

The same loadDir-based fan-out pattern (a goroutine per file/dir, writing
into a shared collection via the loader callback) had the identical bug at
three more call sites that were dropping the mutex loadDir already threads
through for exactly this purpose:
- loadDbModel: unguarded `dbModel.Schemas = append(...)`
- loadDbCatalogs: unguarded `dbServer.Catalogs = append(...)`, plus a
  second race on the outer named-return `err` (the loader closure had no
  named return of its own, so `err =` wrote loadDbCatalogs' return value
  from every worker goroutine)
- loadTables: unguarded `tables = append(...)`

All four now use the mutex (or per-goroutine locals) loadDir/parallel.Run
already make available. loadDbCatalog's index-based schema writes and
loadSchema's writes to the distinct Tables/Views fields were reviewed and
left untouched - they don't share memory across goroutines.

Extended TestLoaderInternals/loadDbModel, loadDbCatalogs and loadTables to
use 2+ schemas/catalogs/tables so the fan-out actually runs concurrent
work; loadDbModel also asserts both tables and views survive the merge.
`go test -race -count=20 ./pkg/storage/filestore/...` is clean.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

18 of 20 new or added lines in 1 file covered. (90.0%)

4714 of 5114 relevant lines covered (92.18%)

0.92 hits per line