Will It Vibe?sync.WaitGroup.Add called inside the goroutine it starts
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
wg.Add(1) is called from inside the goroutine that go starts rather than before the go statement, so Wait() running on another goroutine can return before Add ever executes, undercounting the group and letting the caller proceed while work is still in flight.
Why it matters
sync.WaitGroup requires every Add to happen before the matching Done and before any concurrent Wait call could possibly return; calling wg.Add(1) from inside the goroutine that go just started is a race against the goroutine that might call Wait, because the runtime is free to run Wait to completion before the new goroutine gets scheduled far enough to call Add. When that happens, Wait returns while the goroutine's work has not actually started, which is exactly the guarantee WaitGroup exists to prevent.
How to fix it
Call wg.Add(1) immediately before the go statement that starts the goroutine, in the same goroutine that is doing the launching, and keep wg.Done() (typically deferred) inside the goroutine as the only WaitGroup call that happens there.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo