StrictMiddleware: Custom Error Handler has no access to modified context
I am using a middleware for injecting context values, but when dealing with the error handler, I don't have access to the modified request context with the injected values.
I suggest that the current error handling implementation should be part of the middleware chain.
// Generated code at gen.go
// GetNotifications operation middleware
func (sh *strictHandler) GetNotifications(w http.ResponseWriter, r *http.Request) {
var request GetNotificationsRequestObject
handler := func(ctx context.Context, w http.ResponseWriter, r *http.Request, request interface{}) (interface{}, error) {
return sh.ssi.GetNotifications(ctx, request.(GetNotificationsRequestObject))
}
for _, middleware := range sh.middlewares {
handler = middleware(handler, "GetNotifications")
}
response, err := handler(r.Context(), w, r, request)
if err != nil {
sh.options.ResponseErrorHandlerFunc(w, r, err) // <-- Here, we are not re-utilizing the middleware chain ctx and request. IMO, it should be just another handler wrapping.
} else if validResponse, ok := response.(GetNotificationsResponseObject); ok {
if err := validResponse.VisitGetNotificationsResponse(w); err != nil {
sh.options.ResponseErrorHandlerFunc(w, r, err)
}
} else if response != nil {
sh.options.ResponseErrorHandlerFunc(w, r, fmt.Errorf("unexpected response type: %T", response))
}
}
What I'm doing to circumvent this limitation is:
func ErrorHandler(f nethttp.StrictHTTPHandlerFunc, operationID string) nethttp.StrictHTTPHandlerFunc {
return func(ctx context.Context, w http.ResponseWriter, r *http.Request, request interface{}) (response interface{}, err error) {
resp, err := f(ctx, w, r, request)
if err == nil {
return resp, nil
}
// Custom error handling logic here
return nil, nil
}
strictHandler := NewStrictHandler(client,
[]StrictMiddlewareFunc{
// ...
ErrorHandler,
},
)
I would appreciate this change, thanks for your work!
@jamietanna If you could also take a look into this issue.
If you wish, I can also work on it.
I can propose a pull request solving this issue. Without breaking changes. This would avoid a lot of workarounds for tracing and telemetry
https://github.com/oapi-codegen/oapi-codegen/pull/1838#issuecomment-2487595623 reads like this issue stems from substantial architectural issues
https://github.com/oapi-codegen/oapi-codegen/pull/1838#issuecomment-2487595623 reads as this issue stems from substantial architectural issues
Unfortunately, the required changes are too big. I ended up using ogen instead, and I'm having fewer headaches.