[its-kostya]

Having been plagued by Go's anti-pattern that is goroutine + channels* and having debugged far too many leaked go routines myself, I'd suggest using the pprof package that exposes the /debug/pprof endpoint for your go process. Specifically it exposes runtime profiling data over HTTP in pprof format so you can collect and inspect CPU, heap, goroutine, block, etc.

Debugging becomes, hit the debug endpoint, get a list of all goroutines and their call stack. A leaked goroutine shows up a lot with the same call stack and that's it. There is also a fancy graph you can make the visualizes allocated objects if you have a mem leak and aren't sure if it is me or goroutine.

* Anti-pattern because it is so easy to forgo good program design (like a solid state machine) and reach for a goroutine and communicate back with channels. Do that a few times and your code becomes spaghetti.

[butvacuum]

I'm suprised whatever IDE got used, or some stage of the build, didn't throw a warning for leaving an object that has a dispose interface undisposed.

But, I haven't touched Go. unexciting .net dev...