Skip to content

fix(strict-server): generate correct type for $ref text responses #2225

Merged
mromaszewicz merged 2 commits into
oapi-codegen:mainfrom
mromaszewicz:fix/issue-2190
Feb 16, 2026
Merged

fix(strict-server): generate correct type for $ref text responses #2225
mromaszewicz merged 2 commits into
oapi-codegen:mainfrom
mromaszewicz:fix/issue-2190

Conversation

@mromaszewicz
Copy link
Copy Markdown
Member

No description provided.

mromaszewicz and others added 2 commits February 16, 2026 08:56
Add a minimal reproduction for invalid generated code when reusing
response components. The generated VisitGetTestResponse method attempts
[]byte(response) on a struct type, which does not compile.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
…api-codegen#2190)

When a response is defined as a $ref to a component response with
text/plain content type (and no headers), the strict-server template
generated a struct-embedding type whose Visit method tried to call
[]byte(response) on a struct, which failed to compile.

The root cause was the revert of PR oapi-codegen#1132 (commit 891a067), which had
originally fixed this by making all text responses string types. That
PR was reverted because it broke text responses with headers (oapi-codegen#1676),
which require the struct form with a Body field.

The fix extends the existing multipart special case in Branch 1A of the
strict-interface template to also cover text responses without headers.
This generates a named type alias (e.g. `type GetTest401TextResponse
UnauthorizedTextResponse`) instead of a struct embedding, so
[]byte(response) compiles and works correctly.

Text responses with headers continue to go through Branch 1C (struct
with Body + Headers fields), so oapi-codegen#1676 is unaffected — confirmed by
verifying no diff in internal/test/issues/issue-1676/ping.gen.go.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@mromaszewicz mromaszewicz requested a review from a team as a code owner February 16, 2026 17:14
@mromaszewicz mromaszewicz added this to the v2.6.0 milestone Feb 16, 2026
@jamietanna jamietanna linked an issue Feb 16, 2026 that may be closed by this pull request
@jamietanna jamietanna changed the title Fix/issue 2190 fix(strict-server): generate correct type for $ref text responses Feb 16, 2026
@jamietanna jamietanna added the bug Something isn't working label Feb 16, 2026
@mromaszewicz mromaszewicz merged commit 091742e into oapi-codegen:main Feb 16, 2026
27 checks passed
mromaszewicz added a commit that referenced this pull request Apr 30, 2026
Bring the fiber and iris strict-server interface templates back into parity
with the canonical stdhttp template (`strict-interface.tmpl`). Four pieces of
drift were addressed:

1. Nullable / optional response-header serialization. Both templates now use
   the same three-way switch on `.IsNullable` / `.IsOptional` / default that
   PR #2301 introduced for stdhttp, so unspecified nullable values and nil
   optional pointers are skipped instead of being stringified into the wire
   header.

2. Response-header struct field types. The `{{$opid}}{{$statusCode}}ResponseHeaders`
   struct now uses `{{.GoTypeDef}}` (pointer/nullable-aware) rather than the
   raw `{{.Schema.TypeDecl}}`, matching the type that the typed-body Visit
   function expects.

3. `$ref` Text responses. The fixed-status-code + ref branch now matches
   Multipart and Text together (PR #2225), so `$ref` text responses alias
   directly to the component response type. Iris additionally drops its
   unconditional `type X string` short-circuit, which previously masked
   `$ref`, `$hasHeaders`, and `$fixedStatusCode` for any text response.

4. `$ref` name qualification (fiber only). Switch from `ucFirst` to
   `ucFirstWithPkgName` so external-ref response types carry their package
   qualifier, matching stdhttp and iris.

Regenerated fixtures under `internal/test/strict-server/{fiber,iris}/server.gen.go`
demonstrate the change for items (1) and (2); items (3) and (4) have no
existing fiber/iris fixture coverage.

The no-content `Visit*Response` branch still renders headers unconditionally
in all three templates (including stdhttp); that gap is tracked separately
(#2349) and not addressed here.

Fixes: #2331

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Invalid generated code on reusing responses

2 participants