Fiber Recover middleware panic handling and custom error handler integration

Answer

1. Does the Recover middleware pass the recovered panic as an error to the global Fiber error handler?
Yes. When a panic occurs, Recover captures it and, unless the custom recovery handler explicitly handles the response, forwards the recovered panic as an error to the next middleware in the chain – typically the global error handler.

2. Under what conditions does the custom recovery handler override the global error handler’s response?
The custom handler overrides the global error handler only when it writes a response to the c context and returns nil. In that case Recover stops propagation, and the global error handler is never invoked for that request.

Execution Flow

The typical request pipeline looks like this:

1. Incoming request reaches Recover middleware.
2. A panic occurs during downstream handlers.
3. Recover intercepts the panic and invokes the custom recovery handler (if configured).
4. If the custom handler returns nil after writing a response, Recover halts further processing.
5. If the custom handler returns a non‑nil error (or no custom handler is set), Recover forwards that error to the next middleware.
6. The global error handler receives the error and formats the response according to the application’s error schema.
7. Response is sent to the client.

When Custom Handler Overrides

• Custom handler writes to c.Response() (e.g., sets status code, writes body).
• Custom handler returns nil.
• Because nil indicates no further error propagation, Recover does not call the global error handler.

Otherwise, if the custom handler returns a non‑nil error, the error is propagated to the global error handler, which then applies the standard error schema.

Verification Steps

app := fiber.New()

// Global error handler
app.Use(func(c *fiber.Ctx) error {
    if err := c.Next(); err != nil {
        // Format according to global schema
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{
            "error": err.Error(),
        })
    }
    return nil
})

// Custom recover handler
recoverHandler := func(c *fiber.Ctx, err interface{}) error {
    // Example: log and return nil to override
    log.Printf("panic recovered: %v", err)
    return c.Status(fiber.StatusServiceUnavailable).JSON(fiber.Map{
        "message": "service temporarily unavailable",
    })
}

app.Use(fiber.Recover(fiber.RecoverConfig{Handler: recoverHandler}))

// Route that panics
app.Get("/panic", func(c *fiber.Ctx) error {
    panic("boom")
})

app.Listen(3000)

Run the server and hit /panic. If the custom handler returns nil, you’ll see the 503 response and no invocation of the global error handler. Change the handler to return an error (e.g., return errors.New("recovery error")) and the global handler will format the response instead.

Considerations

• Register Recover before the global error handler to ensure the error is caught early.
• If you want the global error handler to always format the response, let the custom handler return a non‑nil error or omit the handler entirely.
• In Fiber v2.x the API signatures are stable; older versions (<2.0) may have subtle differences.

Diagnostic Question

To confirm the exact behavior in your setup, could you specify the order in which you register the Recover middleware and the global error handler?