datatug / datatug/datatug-cli

fix: remove four pre-existing Go race-detector failures

Open
#247 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
1
Forks
0
Avg merge
2h 20m
Merged PRs (30d)
78

Description

## Summary

The Go race detector reports four independent pre-existing race clusters on unchanged `main`. These failures are outside the Incidentius execution-record changes, but they prevent a repository-wide `go test -race ./...` from being a clean release gate.

Reproduced on `main` at `febb7aa` with Go 1.27.1 on macOS arm64.

## Reproduction

```sh
go test -race \
./apps/datatugapp/datatugui/dtviewers/clouds/gcloud/gcloudui \
./pkg/dtlog \
./pkg/schemers/sqlinfoschema \
./pkg/sqlexecute \
-count=1
```

## Observed race clusters

### 1. GCloud TUI tests and asynchronous callbacks

Affected tests include:

- `TestShowGCloudProjects_*`
- `TestGoFirestoreCollection`
- `TestAddAuthErrorItems_insufficientScopes_actions`

Representative conflict: asynchronous UI callbacks read package/context state while the test restores or replaces the same state. One trace reads `GCloudContext.GetProjects` at `project_context.go:31` while `gcloudui_test.go:501` writes the callback used by `showGCloudProjects`.

### 2. PostHog configuration/client globals

Affected test:

- `TestGetPostHogClient_EmptyDistinctID`

Representative conflicts:

- `withTempConfig` writes config globals in `posthog_coverage_test.go:32` while the package init goroutine reads them through `readPostHogConfig` at `posthog.go:173`.
- Tests and the init goroutine concurrently write/read the package PostHog client and distinct-id globals around `posthog.go:115-116`.

### 3. SQL information-schema aggregation

Affected tests include `TestGetDatabase_*`, including base-table, view, columns-error, and constraints-error cases.

`InformationSchema.GetDatabase` launches parallel functions that concurrently read and write the same error/result slot at `pkg/schemers/sqlinfoschema/schemer.go:54`, `:60`, and `:66`.

### 4. Multi-database SQL execution

Affected test:

- `TestExecute_MultiDispatch`

Parallel workers in `Executor.executeMulti` concurrently write the same result/error slot at `pkg/sqlexecute/executor.go:80` (workers launched through line 91).

## Expected

Each package passes its focused race-detector run, and repository-wide `go test -race ./...` can distinguish new Incidentius regressions from unrelated baseline races.

## Suggested scope

Fix the four clusters independently or split them into child issues. Avoid serializing production work solely to satisfy tests where the production contract is intentionally concurrent; synchronize shared state or collect worker results by index/channel instead.

Contributor guide

Open the contributing guide

Research direction

Start with the reproduction command and the four affected test groups. Inspect the named locations in project_context.go, gcloudui_test.go, posthog.go, posthog_coverage_test.go, schemer.go, and executor.go to understand each race cluster. Done means the focused race-detector runs pass and go test -race ./... no longer reports these baseline failures.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.