Generating strict servers using 2.1.0 breaks casting of imported components when moving from 2.0.0. · Issue #2010 · oapi-codegen/oapi-codegen · GitHub
Skip to content

Generating strict servers using 2.1.0 breaks casting of imported components when moving from 2.0.0. #2010

Closed

Description

@MathewSharff

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)
}

Setup:

open_api.yaml

openapi: 3.0.1
info:
  description: An example schema
  title: ExampleAPI
  version: 1.0.0
paths:
  /example:
    get:
      operationId: getExample
      responses:
        200:
          description: OK
        400:
          $ref: "#/components/responses/400"
components:
  responses:
    400:
      content:
        application/json:
          schema:
            properties:
              message:
                type: string
            required:
              - message
            type: object
      description: Bad Request

open_api.cfg.yaml

package: api
generate:
  chi-server: true
  models: true
  strict-server: true
output: ./api/api.go
output-options:
  skip-prune: true

open_api_other.yaml

openapi: 3.0.1
info:
  description: Another example schema
  title: OtherAPI
  version: 1.0.0
paths:
  /example:
    get:
      operationId: getOtherExample
      responses:
        200:
          description: OK
        400:
          $ref: "./open_api.yaml#/components/responses/400"

open_api_other.cfg.yaml

package: otherapi
generate:
  chi-server: true
  models: true
  strict-server: true
import-mapping:
  ./open_api.yaml: github.com/oapiexample/api/api
output: ./otherapi/api.go

generate.go

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 }

I believe pull request #1387 introduced this change.

Activity

  1. added theissue type on Jul 16, 2025
  2. added this to the v2.6.0 milestone on Jul 16, 2025
  3. mromaszewicz commented on Apr 22, 2026

    @mromaszewicz
    Member

    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 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.

  4. jamietanna commented on Apr 30, 2026

    @jamietanna
    Member

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions