http server Bind errors bypass middleware chain (logging/tracing/recovery not executed)

[robotmeta]

Title

http server Bind errors bypass middleware chain (logging/tracing/recovery not executed)

---

Description

In the current go-kratos HTTP server implementation, request binding (Bind) happens before middleware execution. This leads to a critical issue:

If an error occurs during the binding phase (e.g., invalid request format, missing fields, or even a panic like nil pointer dereference), the middleware chain is never executed.

As a result:

• Logging middleware is skipped
• Tracing middleware is skipped
• Metrics middleware is skipped
• Recovery middleware cannot catch panics

This effectively breaks observability and stability guarantees.

---

Steps to Reproduce

1. Create a HTTP handler with a request struct

2. Send an invalid request (e.g., malformed JSON or missing required fields)

3. Or trigger a panic inside binding (e.g., custom binder or pointer issue)

4. Observe that:

   • No logs are generated
   • No tracing span is recorded
   • No metrics are emitted
   • Panic is not recovered

---

Expected Behavior

Even if binding fails or panics occur:

• Middleware chain should still be executed
• Logging / tracing / metrics should capture the failure
• Recovery middleware should handle panics

---

Actual Behavior

• Binding errors short-circuit the request lifecycle
• Middleware chain is completely bypassed
• Observability is lost
• Panic may crash the process (depending on context)

---

Root Cause Analysis

From current behavior, it appears that:

Request → Bind → Handler → Middleware

Instead of the more robust design:

Request → Middleware → Bind → Handler

Because binding occurs before middleware, any failure at this stage prevents middleware from executing.

---

Suggested Solutions

Option 1: Move Bind into middleware stage (Recommended)

Make binding part of the middleware chain:

Request → Middleware (including Bind) → Handler

This ensures:

• All errors are observable
• Recovery middleware can catch panics
• Consistent request lifecycle

---

Option 2: Wrap Bind with internal middleware-like handling

If moving Bind is not feasible:

• Wrap binding logic with:

  • logging
  • tracing
  • panic recovery

But this duplicates middleware responsibilities and is less clean.

---

Option 3: Provide hook / interceptor before Bind

Expose a hook like:

BeforeBind(ctx, req)

So users can inject observability logic manually.

---

Option 4: Ensure recovery at the outermost layer

Guarantee that panic recovery exists outside Bind, even before middleware.

---

Additional Context

This issue has significant impact in production systems:

• Silent failures (no logs, no traces)
• Observability blind spots
• Difficult debugging
• Potential process crashes

---

Environment

• go-kratos version: (please fill)
• Go version: (please fill)
• OS: (please fill)

---

Summary

The current execution order makes the system fragile and non-observable in case of binding errors. Adjusting the lifecycle so middleware wraps the entire request (including Bind) would greatly improve robustness and observability.

---

[dosubot]

Hi @robotmeta! I'm Dosu and I’m helping the kratos team.

Thanks for the detailed write-up. I dug into the codebase to clarify the actual request lifecycle, and your core observation is correct — but the picture is a bit more nuanced due to Kratos's two-tier middleware system.

The actual execution order is:

Request → HTTP Filters → Handler Function (Bind → Service Middleware → Service Method) → Response

In protoc-generated handlers, binding (ctx.Bind, ctx.BindQuery, ctx.BindVars) happens inside the handler function but before ctx.Middleware() is called [1]. For example, in a generated GET handler [2]:

func _Greeter_SayHello0_HTTP_Handler(srv GreeterHTTPServer) func(ctx http.Context) error {
    return func(ctx http.Context) error {
        var in HelloRequest
        if err := ctx.BindQuery(&in); err != nil { return err }  // binding first
        if err := ctx.BindVars(&in); err != nil { return err }   // binding first
        http.SetOperation(ctx, OperationGreeterSayHello)
        h := ctx.Middleware(func(ctx context.Context, req interface{}) (interface{}, error) {
            return srv.SayHello(ctx, req.(*HelloRequest))        // service middleware wraps this
        })
        out, err := h(ctx, &in)
        // ...
    }
}

This means:

• HTTP-level filters (registered via Filter() option or route-level filters) do execute before binding, since they wrap the entire handler function [3] [4]. If you register recovery/logging/tracing as HTTP filters, they will catch binding errors and panics.
• Service-level middleware (registered via Middleware() option, matched by operation) executes after binding [5], so these are indeed bypassed on binding failures — which is the behavior you're describing.

Practical workaround: If you need logging, tracing, metrics, and recovery to cover binding errors, register them as HTTP-level filters (http.Filter(...)) rather than service-level middleware (http.Middleware(...)). HTTP filters wrap the entire handler including the binding phase, so they will observe binding failures and catch panics.

That said, your point about the default experience is valid — most users register observability concerns as service middleware (since that's what the docs and examples tend to emphasize), and those do miss binding errors. Moving binding inside the middleware chain (your Option 1) would make the default behavior more robust without requiring users to understand the two-tier distinction.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[shenqidebaozi]

@dosu

[kratos-ci-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@dosu

[dosubot]

The issue raises a valid concern. Here's a summary of the actual request lifecycle in Kratos and a practical workaround:

Actual execution order:

Request → HTTP Filters → Handler Function (Bind → Service Middleware → Service Method) → Response

Kratos has a two-tier middleware system [1] [2]:

1. HTTP-level filters (http.Filter(...)) — wrap the entire handler including binding. These execute before binding occurs [3].
2. Service-level middleware (http.Middleware(...)) — execute after binding, wrapping only the service method call [4].

In protoc-generated handlers, binding (ctx.Bind, ctx.BindQuery, ctx.BindVars) runs inside the handler function before ctx.Middleware() is invoked [5] [6]. So if binding fails, service-level middleware (logging, tracing, metrics, recovery) is indeed bypassed.

Workaround: Register observability concerns (logging, tracing, recovery) as HTTP-level filters via http.Filter(...) rather than service-level middleware. HTTP filters wrap the entire handler function — including the binding phase — so they will observe binding errors and catch panics during binding.

httpSrv := http.NewServer(
    http.Filter(recoveryFilter, loggingFilter, tracingFilter), // covers binding errors
)

That said, the issue author's point stands — most users register these as service middleware (since that's what examples and docs tend to show), and the distinction between the two layers isn't immediately obvious. Moving binding inside the middleware chain (Option 1 in the issue) would make the default behavior more robust without requiring users to understand this two-tier architecture.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.