Documentation
¶
Overview ¶
Package goroutines provides a small helper for tests that need to assert goroutine leaks — specifically, the closeWg accumulation scenarios in the streaming pipeline where rapid seek/close cycles can spawn background goroutines that outlive the request.
Goroutine counting is inherently noisy: the Go runtime spins up internal goroutines (GC, sysmon, http2 pingers, finalizer goroutines) that come and go independently of test code. The Snapshot / AssertReturnedToBaseline pattern below tolerates that noise with a small slack window and a polling timeout, while still catching the "N spawned, none reaped" leaks this codebase has historically been vulnerable to.
Usage:
snap := goroutines.Take(t) doWorkThatMustNotLeak() snap.AssertReturnedToBaseline(t, 5*time.Second)
The assertion polls runtime.NumGoroutine() until it lands within DefaultSlack of the original count or the timeout fires.
Index ¶
Constants ¶
const DefaultSlack = 5
DefaultSlack is the tolerance allowed when comparing goroutine counts before and after a test phase. Set high enough to absorb runtime jitter (GC workers, finalizers) but low enough that a real leak of >5 goroutines is caught.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Snapshot ¶
type Snapshot struct {
// contains filtered or unexported fields
}
Snapshot is a point-in-time goroutine count.
func Take ¶
Take records the current goroutine count. Call once before the code under test, then call AssertReturnedToBaseline after it should have settled.
func (Snapshot) AssertReturnedToBaseline ¶
AssertReturnedToBaseline polls runtime.NumGoroutine until it reaches baseline + DefaultSlack or until timeout elapses. On timeout the test fails with a diagnostic that includes the current and target counts and a partial dump of the goroutine stacks — usually enough to locate the leak source without rerunning under a profiler.
func (Snapshot) AssertReturnedToBaselineWithSlack ¶
AssertReturnedToBaselineWithSlack is the explicit-tolerance variant. Use when the code under test is known to spawn a fixed number of background goroutines that are part of its design (e.g. a worker pool).