@greptileai

Greptile Summary

This PR adds support for handler-specific middleware in the gofiber code generation path, mirroring a capability that already exists for chi/echo. It introduces a new HandlerMiddlewareFunc type (func(c *fiber.Ctx, next fiber.Handler) error) and a HandlerMiddlewares []HandlerMiddlewareFunc field on FiberServerOptions, allowing users to inject middleware that runs after path/query parameters are parsed and security scopes are set in context — but before the handler itself executes.

Key changes:

• fiber-middleware.tmpl: Each generated handler now wraps its call in a middleware chain (iterated in reverse so index 0 runs first). Also fixes a pre-existing issue where sanitizeGoIdentity was missing from the security scope key construction, which could produce invalid Go identifiers for non-standard scheme names.
• fiber-handler.tmpl: Threads options.HandlerMiddlewares through to the ServerInterfaceWrapper.
• internal/test/issues/issue518/: A new end-to-end test covering both basic registration and the auth middleware use-case (differentiating secured vs. unsecured endpoints via security scopes set in context).

Confidence Score: 5/5

This PR is safe to merge — it is a purely additive change and is well-covered by tests.

The change is additive: existing callers that don't set HandlerMiddlewares get the same generated code path (an empty slice causes the loop to no-op). The middleware chaining closure correctly captures loop variables (m and next) to avoid the classic Go closure-in-loop issue. The execution order (first element runs outermost) is intuitive and matches chi's ApplyChiMiddlewareFirstToLast behavior. Tests cover registration, middleware interop, and the secured/unsecured endpoint distinction.

No files require special attention.

_{Reviews (1): Last reviewed commit: "chore(fiber): regenerate existing fiber ..." | Re-trigger Greptile}

Thank you!