Description

The forcetypeassert linter is explicitly disabled in .golangci.yml (line 15):

linters:
  default: all
  disable:
    - forcetypeassert   # <-- disabled

This linter flags bare type assertions v.(T) that don't use comma-ok (v, ok := x.(T)). Bare assertions panic at runtime on type mismatch — they are Go's equivalent of an unchecked cast.

Why This Matters

With forcetypeassert disabled, there is no CI protection against new bare type assertions introduced by contributors. A missing comma-ok in error handling, context value extraction, or interface dispatch becomes a latent crash that only triggers in production.

This is the exact category of bug that caused:

• Panics at on context close, v1.33.0 #1205 — nil RequestCtx panic from pool
• Panic during shutdown #1987 — nil perIPConnCounter panic on shutdown
• Bug: fasthttp.RequestCtx panic #2026 — zero-value RequestCtx panic

Current Bare Assertions in Codebase

There are 44 bare type assertions from sync.Pool.Get() results (see #2231). These are controlled but unprotected by CI.

There are also safe comma-ok assertions in the codebase (e.g., tcpdialer.go:432, http.go:1021, server.go:858, peripconn.go:125) — showing the codebase already uses both patterns inconsistently.

Suggested Fix

1. Remove forcetypeassert from the disable list in .golangci.yml
2. Add //nolint:forcetypeassert annotations to the known-safe pool assertions (the 44 instances from safety: 44 bare type assertions from sync.Pool without comma-ok — panics on pool corruption #2231)
3. All new code with bare assertions will fail CI, forcing developers to use comma-ok or justify the assertion

This follows the same pattern as the existing //nolint:errcheck and // #nosec G115 annotations already in the codebase.

Impact

• Medium severity — no immediate runtime risk, but prevents future regressions from reaching main
• Zero performance impact — lint-only change