They do once you restart the server. Unsure what the "phase 3 monitoring" shows where the goroutines go down gradually. If you have new code to deploy you must recompile and therefore restart and those goroutines are gone anyway.

This feels like an AI made-up story but I'm not sure I understand the point of making this up.

However, goroutine leak is interesting! I hope what I learned from this post isn't hallucination. For example, how could the subscriber send messages/heartbeats to the closed goroutine without an error...

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.

Channels are buffered in Go, they will not grow unbounded.

> Tickers Are Not Garbage Collected

It used to be necessary in older versions to call ticker.Stop(), but in recent versions it's no longer necessary.

    // Start goroutines
    go s.pumpMessages(ctx, sub)
    go s.heartbeat(ctx, sub)
    
    // Monitor the connection
    go s.monitorConnection(ctx, sub)

In general this article screams AI with most of the conclusions being hallucinated. Goroutine leaks are real, but it's hard to trust any of the article's conclusions

I see this mentality now and again in DevOps teams. It reminds me of that "Not great, not terrible." quote from Chernobyl.

There are just so many things being monitored, but holistic understanding is not always there. And that's why I believe more and more that the developers of a products should also (partly) be DevOps, don't have a completely separate team with zero overlap.