# Go Code Review

Review {{input}} for correctness, idiomatic style, and best practices.

## Error Handling
- Every error return must be checked — never assign to `_` unless explicitly intentional
- Wrap errors with context using `fmt.Errorf("doing X: %w", err)` for stack-friendly traces
- Use sentinel errors (`var ErrFoo = errors.New(...)`) or custom types for errors callers need to match
- Avoid `panic` in library code; reserve it for truly unrecoverable programmer errors

## Concurrency
- No goroutine leaks — every goroutine must have a clear exit condition
- Protect shared state with `sync.Mutex` or channels; no unsynchronised map reads/writes
- Pass `context.Context` as the first argument to all blocking/long-running functions
- Use `errgroup` for fan-out goroutines that need coordinated cancellation

## Resource Management
- Use `defer` to close files, DB connections, response bodies, and locks immediately after opening
- Check the error from `rows.Close()` and `resp.Body.Close()` — they can fail
- Drain `http.Response.Body` before closing to allow connection reuse

## Style and Correctness
- Keep interfaces small — prefer one or two methods; accept interfaces, return concrete types
- Package names should be short, lowercase, no underscores; avoid `util`, `common`, `helper`
- Initialise structs with field names, not positional values
- Avoid named return values except where they genuinely improve readability (e.g. `(n int, err error)`)

## Security
- Parameterise all DB queries; no string concatenation in SQL
- Validate and sanitise all external inputs; do not trust `r.URL.Path` or query params
- No secrets in logs, error messages, or HTTP responses

---
List findings as **Critical** (data races/panics/security) -> **Major** (bugs/goroutine leaks/missing error checks) -> **Minor** (style/naming/readability). Cite each location and suggest the concrete fix.