Describe the bug
In internal/base/server/http.go, the Gin engine is initialized via gin.New() without mounting a recovery middleware. When a panic occurs in any handler or middleware, the connection is dropped without returning a proper HTTP response to the client.
Current behavior
gin.New() (unlike gin.Default()) does not install any recovery middleware. When a panic propagates out of a handler:
- The Go runtime's
net/http server recovers per-connection, preventing the process from exiting.
- But it closes the connection without writing any response body.
- The client sees a connection reset / EOF rather than a structured 5xx response.
- The panic is not logged through the project's logging facility (
pacman/log).
To Reproduce
This is a defensive coding issue rather than a directly triggerable bug. To verify the behavior, one can temporarily add panic("test") to any controller handler and observe that the client receives a connection error instead of an HTTP response.
Expected behavior
The server should return a unified 500 JSON response with reason: base.unknown, consistent with how other errors are handled in the project (see internal/base/handler/handler.go). The panic message and stack trace should be logged via the project's logger for diagnostics.
Additional context
I'd like to submit a PR to fix this by adding a middleware.Recovery() that:
- Logs the panic message and full stack trace via
log.Errorf + debug.Stack().
- Returns the standard error response using
handler.NewRespBody + TrMsg to stay consistent with the rest of the codebase.
- Is mounted as the first middleware in
http.go so it covers all subsequent middleware and handlers.
Describe the bug
In
internal/base/server/http.go, the Gin engine is initialized viagin.New()without mounting a recovery middleware. When a panic occurs in any handler or middleware, the connection is dropped without returning a proper HTTP response to the client.Current behavior
gin.New()(unlikegin.Default()) does not install any recovery middleware. When a panic propagates out of a handler:net/httpserver recovers per-connection, preventing the process from exiting.pacman/log).To Reproduce
This is a defensive coding issue rather than a directly triggerable bug. To verify the behavior, one can temporarily add
panic("test")to any controller handler and observe that the client receives a connection error instead of an HTTP response.Expected behavior
The server should return a unified 500 JSON response with
reason: base.unknown, consistent with how other errors are handled in the project (seeinternal/base/handler/handler.go). The panic message and stack trace should be logged via the project's logger for diagnostics.Additional context
I'd like to submit a PR to fix this by adding a
middleware.Recovery()that:log.Errorf+debug.Stack().handler.NewRespBody+TrMsgto stay consistent with the rest of the codebase.http.goso it covers all subsequent middleware and handlers.