You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Generating strict servers using 2.1.0 breaks casting of imported components when moving from 2.0.0. #2010
Example code that breaks when generating using 2.1.0+:
package main
import (
"fmt"
"github.com/oapiexample/api"
"github.com/oapiexample/otherapi"
)
func main() {
var a api.GetExampleResponseObject
var b otherapi.GetOtherExample400JSONResponse
switch a.(type) {
case api.GetExample400JSONResponse:
b = otherapi.GetOtherExample400JSONResponse(a.(api.GetExample400JSONResponse)) // <- this line no longer compiles
}
fmt.Println(b.Message)
}
package oapiexample
//go:generate go run github.com/deepmap/oapi-codegen/v2/cmd/oapi-codegen@v2.0.0 --config open_api.cfg.yaml ./open_api.yaml
//go:generate go run github.com/deepmap/oapi-codegen/v2/cmd/oapi-codegen@v2.0.0 --config open_api_other.cfg.yaml ./open_api_other.yaml
When I look at the generated code, this line changes from
type GetOtherExample400JSONResponse struct{ externalRef0.N400JSONResponse }
to
type GetOtherExample400JSONResponse struct{ externalRef0.N400 }
The GetExample400JSONResponse type that references the same response component continues to embed the N400JSONResponse type.
type GetExample400JSONResponse struct{ N400JSONResponse }
The issue is that we generate models separately from the strict server wrappers, and we have no knowledge about whether the external spec generated strict server models.
To date, all the code I've written assumed that the external spec was mainly used for models, and I never planned for having external refs be used so deeply, so the code isn't fully tested.
In this case, my preference would be for the strict server wrappers to only embed something that comes from the models generation option, and not from other strict servers, however, this is a pretty large change which would need to be gated behind an opt-in flag, and until I attempt it, I don't know how it would break.
Another option might be to revert what #1387 did, and document a limitation - in that if you're generating strict servers, and importing request/response models across module boundaries, the external package must have been generated with the strict server option.
I can't remember if #1387 was something that was actively stopping progression on #1378 which was functionality that we wanted to fix
I think if we can see if reverting #1387 in a reasonable way without breaking too much other stuff would be fine - especially if the fix in #1387 fix is actually causing more of an issue
Activity
mromaszewicz commentedon Apr 22, 2026
Man, this is a hard one.
The issue is that we generate models separately from the strict server wrappers, and we have no knowledge about whether the external spec generated strict server models.
To date, all the code I've written assumed that the external spec was mainly used for models, and I never planned for having external refs be used so deeply, so the code isn't fully tested.
In this case, my preference would be for the strict server wrappers to only embed something that comes from the
modelsgeneration option, and not from other strict servers, however, this is a pretty large change which would need to be gated behind an opt-in flag, and until I attempt it, I don't know how it would break.Another option might be to revert what #1387 did, and document a limitation - in that if you're generating strict servers, and importing request/response models across module boundaries, the external package must have been generated with the strict server option.
Overhaul anonymous schema hoisting
Overhaul anonymous schema hoisting
Overhaul anonymous schema hoisting (#2348)
jamietanna commentedon Apr 30, 2026
I can't remember if #1387 was something that was actively stopping progression on #1378 which was functionality that we wanted to fix
I think if we can see if reverting #1387 in a reasonable way without breaking too much other stuff would be fine - especially if the fix in #1387 fix is actually causing more of an issue
revert external-ref carve-out in strict-server response embedding (#2010
test: describe what the response_cast fixture now covers
fix: handle untyped strict response bodies (#2514)
feat!: replace std-http-server and strict-server with one server option