Description

Throughout the codebase, sync.Pool.Get() results are cast to concrete types using bare type assertions (no comma-ok):

zr := v.(*brotli.Reader)   // panics if v is wrong type
sw := v.(stackless.Writer)  // panics if v is wrong type

If a pool is ever corrupted (wrong type Put back, double-release, or nil stored where a typed value is expected), these panic immediately with no recovery context — crashing the server.

Affected Locations (44 instances)

Current State

All are guarded by preceding nil checks and pool types are controlled (only known types are Put back). However:

1. No compile-time safety — a refactoring mistake silently becomes a runtime panic
2. forcetypeassert linter is explicitly disabled in .golangci.yml (line 15), which would catch exactly this class of bug
3. No debug context when panic occurs — bare assertion panics give only the type mismatch, not which pool or why

Suggested Fix

Option A (minimal): Re-enable the forcetypeassert linter with //nolint:forcetypeassert annotations on the known-safe pool assertions. This ensures new non-pool assertions are caught in CI.

Option B (robust): Wrap pool assertions in a helper:

func poolGet[T any](p *sync.Pool) T {
    v := p.Get()
    if v == nil {
        var zero T
        return zero
    }
    t, ok := v.(T)
    if !ok {
        panic(fmt.Sprintf("BUG: pool corruption: expected %T, got %T", zero, v))
    }
    return t
}

This provides a clear diagnostic message instead of a bare type assertion panic.

Impact

• Low probability today (controlled pool types), but HIGH severity when triggered — unhandled panic crashes the server
• Disabling forcetypeassert means future regressions in non-pool code won't be caught by CI