Closes: oapi-codegen#1887 Route registration was emitted in sorted path order, so reordering paths in the spec had no effect. On routers that match in registration order (Fiber, Gorilla/mux) this left users no way to disambiguate overlapping paths — e.g. a request for `/templates/privates/shortcuts` always went to `/templates/privates/{id}` rather than `/templates/{visibility}/shortcuts`. kin-openapi stores paths in a map, losing declaration order at parse time, so enable its origin tracking (`Loader.IncludeOrigin`) to recover each path's source line onto the OperationDefinition (SpecOrder). Each GenerateXServer now renders its registration template with operations sorted by SpecOrder, via a new GenerateTemplatesIntoBuffer that composes passes into one buffer (GenerateTemplates wraps it). Model and interface generation are intentionally left in the old sorted order to preserve any existing ordering behavior — in particular the order-dependent fallback in name-collision resolution. Only handler registration follows spec order. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Uh oh!

Commits

Commits on Jul 13, 2026

Register handlers in spec order