mir-backend-golisted
Install: claude install-skill anantbhandarkar/make-it-right
# /mir-backend-go · Make It Right (Go runtime)
The middle tier. `mir-backend` decides **what is correct** (any language). The framework module (e.g. `mir-backend-go-gin`) knows the **library's mechanics**. This tier owns what is true for **all Go backends because they run on the Go runtime** — the goroutine scheduler, memory model, and process model that Gin, Fiber, Echo, chi, and raw `net/http` all inherit.
**Runtime assumed:** Go 1.22+. Load order: `mir-backend` → `mir-backend-go` → `<framework module>`.
## The Go footguns AI walks into (framework-agnostic)
### 1. Goroutine leaks — the #1 Go reliability bug
A goroutine blocked forever on a channel send or receive with no exit path leaks memory and any handles (DB connections, file descriptors) it holds. The runtime never garbage-collects a blocked goroutine. Under load, hundreds of leaked goroutines exhaust memory silently.
- **Always give every goroutine a way to exit.** The standard mechanism: accept a `context.Context` as the first argument and `select` on `ctx.Done()` alongside the blocking operation.
- Leak pattern — no exit:
```go
// WRONG: goroutine blocked forever if nobody reads ch
go func() { ch <- result }()
```
- Fixed — context exit:
```go
go func() {
select {
case ch <- result:
case <-ctx.Done():
}
}()
```
- Use `goleak` (uber-go/goleak) in tests to catch leaks automatically.
- Long-running worker loops must `select` on `ctx.Done()` in every iteration.
### 2. Cont