Fix generated middleware composition across the finalized route graph#698
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 10609cb75d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Args: []ast.Expr{handler, call(id("registeredMiddlewares"))}, | ||
| Ellipsis: token.Pos(1), | ||
| } | ||
| return handler |
There was a problem hiding this comment.
Update backend-only middleware assertions
With this change returning the backend-only handler unwrapped at the route level, the backend generation tests still look for the old route-local gowdkruntime.ApplyMiddlewares(...) call. I verified go test ./internal/appgen -run TestGenerateBackendAppRegistersBackendRoutes -count=1 and go test ./internal/appgen -run TestGenerateBackendAppWiresSecurityHeaders -count=1 both fail on those stale expected strings, so the appgen CI gate remains blocked until those expectations are updated to the new finalized-wrapper output.
Useful? React with 👍 / 👎.
Problem
Generated
RegisterMiddlewaremiddleware was applied only to the"/"fallback handler inside the generated mux. More-specific generated routes—such as dynamic sitemap and realtime endpoints—and routes mounted later by lifecycle services could bypass the documented app-wide middleware chain.Changes
Handler().Application.Muxraw for lifecycle route registration while serving it through a finalized wrappedApplication.Handler.ServeMux()expose the generated route graph behind the same finalized middleware wrapper.App(),Handler(),ServeMux(), and caller-added routes.Regression coverage
Validation
go test ./internal/appgen -updatego test ./internal/appgen ./runtime/app