@rjl493456442 I'm gonna leave this in draft as it's only the test demonstration for now; please let me know if you think it's worth addressing.

We can break down the situation and see if it’s “worth fixing” versus just ignoring in tests.

⚙️ What’s happening

• snapshot.diskLayer.generate() can complete “too early,” setting genMarker = nil.
• Meanwhile, diskLayer.stopGeneration() may race with that state, leaving the generate() goroutine blocked forever since it never receives on genAbort.
• The practical effect:

  • Disable() leaks the goroutine.

  • Journal() appears to clean up correctly, so normal usage doesn’t accumulate leaks.

  • Tests using goleak.Verify*() will consistently flag this unless you explicitly ignore it.

📌important on Why it matters

• Production impact: If Journal() is the usual cleanup path, then in real-world usage resources are released and the leak doesn’t accumulate. That makes it low severity.
• Testing impact: You’ll always have to add an ignore for Disable(). This is annoying but predictable.
• Code hygiene: Goroutine leaks—even benign ones—are usually worth fixing because they signal a race or incomplete lifecycle management. Even if harmless now, they can become problematic if code evolves.

🛠️ Options

1. Fix the race

   • Ensure stopGeneration() always signals genAbort regardless of genMarker state.
   • Or restructure so generate() checks for completion before blocking.
   • This removes the need for ignores in tests and makes lifecycle management airtight.

2. Document + Ignore

   • Accept that Disable() leaks, document it clearly, and add goleak.IgnoreCurrent() or similar in tests.
   • This is pragmatic if the leak is provably harmless and fixing it would add complexity or risk.

Recommendation
If you’re already touching this code, fixing it is cleaner. Goroutine leaks are one of those “small now, big later” issues—especially in libraries where users may call Disable() in unexpected ways. Even if it’s only a test annoyance today, tightening the lifecycle avoids future surprises.

That said, if the code is stable, rarely touched, and the fix would be invasive, documenting and ignoring in tests is defensible. It depends on whether you want to prioritize developer ergonomics (no ignores, clean tests) or minimal churn (leave as-is).

👉I'm Curious: do you see Disable() being used in production paths, or is it really just a test helper for you? If it’s test-only, ignoring might be fine. If it’s exposed to users, I’d lean toward fixing.