Severity: P3 | Subsystem: routing | Category: bug
Location: /home/kyleg/containers/atxfpv.org/skwad/main.go:240,259-274
What
The only middleware is corsMiddleware; there is no recover() anywhere in the codebase. A panic in a handler is caught by net/http per-connection recovery so the process survives, but the client gets an abrupt empty response with no logged context and no clean 500.
Suggested fix
Add a recoverMiddleware that defers recover(), logs the stack, and writes a 500.
Verification
Verified against current code. main.go:240 wraps the mux only in corsMiddleware (and noCacheMiddleware on the static GET / route at line 237); grep for recover() across all .go files (main.go, api/handlers.go, api/feedback.go, freq/.go, db/.go) returns zero matches — there is no app-level panic recovery anywhere. The server uses http.ListenAndServe (main.go:243), i.e. standard net/http, whose conn.serve defers a built-in recover, so a handler panic does NOT crash the process — confirming the finding's own caveat. The client gets an abrupt aborted/empty response and the stack trace goes to net/http's default logger rather than the app's logging, with no clean 500. All technical claims in the finding hold. Lowered severity to P3: the finding itself notes the process survives, so there is no downtime or data-loss path; the real impact is a degraded error response plus a stack landing in the default logger instead of structured app logs — a robustness/observability hardening gap, not a correctness defect on a user-facing path under normal operation. For an app this size that's a P3 'should add' rather than P2.
Filed from the 2026-05-30 multi-agent codebase review.
Severity: P3 | Subsystem: routing | Category: bug
Location:
/home/kyleg/containers/atxfpv.org/skwad/main.go:240,259-274What
The only middleware is corsMiddleware; there is no recover() anywhere in the codebase. A panic in a handler is caught by net/http per-connection recovery so the process survives, but the client gets an abrupt empty response with no logged context and no clean 500.
Suggested fix
Add a recoverMiddleware that defers recover(), logs the stack, and writes a 500.
Verification
Verified against current code. main.go:240 wraps the mux only in corsMiddleware (and noCacheMiddleware on the static GET / route at line 237); grep for recover() across all .go files (main.go, api/handlers.go, api/feedback.go, freq/.go, db/.go) returns zero matches — there is no app-level panic recovery anywhere. The server uses http.ListenAndServe (main.go:243), i.e. standard net/http, whose conn.serve defers a built-in recover, so a handler panic does NOT crash the process — confirming the finding's own caveat. The client gets an abrupt aborted/empty response and the stack trace goes to net/http's default logger rather than the app's logging, with no clean 500. All technical claims in the finding hold. Lowered severity to P3: the finding itself notes the process survives, so there is no downtime or data-loss path; the real impact is a degraded error response plus a stack landing in the default logger instead of structured app logs — a robustness/observability hardening gap, not a correctness defect on a user-facing path under normal operation. For an app this size that's a P3 'should add' rather than P2.
Filed from the 2026-05-30 multi-agent codebase review.