refactor: use WaitGroup.Go to simplify code

[purelualight]

Adopt sync.WaitGroup.Go (Go 1.25) to simplify tracked goroutine spawning.

This replaces the error-prone trio of wg.Add(1), go func(), and defer wg.Done() with a single, self-contained call.

More info: golang/go#63796

[greptile-apps]

Greptile Summary

This PR adopts sync.WaitGroup.Go (introduced in Go 1.25) across 18 files to replace the boilerplate wg.Add(1) / go func() { defer wg.Done() ... }() pattern. The project's go.mod already declares go 1.26, so the new API is available. All 30+ replacements are semantically equivalent — wg.Go(f) is defined as wg.Add(1); go func() { defer wg.Done(); f() }() — making this a safe, mechanical refactor with no behaviour changes.

Confidence Score: 5/5

Safe to merge — purely mechanical refactor with no logic changes and confirmed API availability in Go 1.25+.

All replacements are semantically identical to the original code; the Go version constraint (1.26) guarantees WaitGroup.Go availability; no new logic is introduced.

No files require special attention.

Important Files Changed

Filename	Overview
cli/operator/node.go	Replaces Add(1)/go func()/defer Done() trio with wg.Go() in slot pruning loop — semantically equivalent.
operator/duties/scheduler.go	Five goroutine launches refactored to wg.Go() — duty execution and background tasks all equivalent.
network/topics/controller_test.go	Outer goroutine uses wg.Go(); body still calls wg.Add(1) for inner goroutines — pre-existing pattern, semantically equivalent, correct because Add() is called before the outer wg.Done().
protocol/v2/ssv/runner/committee.go	Worker goroutine loop refactored to wg.Go() — no semantic change.
operator/duties/attester.go	Background subscription goroutine converted to wg.Go() — equivalent.
operator/duties/sync_committee.go	Background subscription goroutine converted to wg.Go() — equivalent.
hprobe/prober.go	Concurrent probe launches converted to wg.Go() — equivalent.
utils/hashmap/hashmap_test.go	Nested wg.Go() usage (outer wwg.Go wraps inner wg.Go loop) — pre-existing pattern, correctly equivalent.
utils/ttl/map_test.go	Mirrors hashmap_test.go changes with nested wg.Go() — equivalent.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant WaitGroup
    participant Goroutine

    Note over Caller,Goroutine: Old pattern
    Caller->>WaitGroup: Add(1)
    Caller->>Goroutine: launch goroutine with defer Done
    Goroutine-->>WaitGroup: Done deferred on return
    Caller->>WaitGroup: Wait

    Note over Caller,Goroutine: New pattern via WaitGroup.Go
    Caller->>WaitGroup: Go(f)
    WaitGroup->>WaitGroup: Add(1) internally
    WaitGroup->>Goroutine: launch goroutine
    Goroutine-->>WaitGroup: Done internally on return
    Caller->>WaitGroup: Wait

Loading

_{Reviews (1): Last reviewed commit: "refactor: use WaitGroup.Go to simplify c..." | Re-trigger Greptile}

[nkryuchkov]

Thank you for the contribution

[iurii-ssv]

Good stuff, @purelualight can you also fix the failed linter pipeline ?

[momosh-ssv]

What do you think about using a separate innerWg for these goroutines? Seems that calling wg.Add(1) from inside a closure that's itself counted by the same wg is fragile — it works today because the for-loop always runs to completion before the outer goroutine returns, but a future early-return (e.g. on ctx cancel) could let the trailing wg.Wait() unblock before all inner Add calls land, racing any subsequent reuse of the same wg.

[purelualight]

Good stuff, @purelualight can you also fix the failed linter pipeline ?

@iurii-ssv @nkryuchkov Thank you for your review. I’ve resolved the conflicts and fixed the lint issues (I removed the extra blank lines). Please review it again.

[iurii-ssv]

@purelualight the CI linter seems to have failed again, can you run make lint locally to figure out why and fix it ?

[github-actions]

This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 30 days if there are no updates. Please comment if you would like to keep it open.