Skip to content

Fix 204 responses still including a content schema - #1087

Open
TZK- wants to merge 2 commits into
knuckleswtf:v5from
TZK-:fix/204-response-content-type-comparison
Open

Fix 204 responses still including a content schema#1087
TZK- wants to merge 2 commits into
knuckleswtf:v5from
TZK-:fix/204-response-content-type-comparison

Conversation

@TZK-

@TZK- TZK- commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Problem

Responses documented with status 204 still get a full content schema in the generated OpenAPI spec, instead of the expected empty response.

#[ResponseFromApiResource(BookResource::class, Book::class, 204)]
// or
#[Response(status: 204)]
public function destroy(Book $book)
{
    $book->delete();

    return response()->noContent();
}

Generated openapi.yaml (current, incorrect):

responses:
  204:
    description: ''
    content:
      application/json:
        schema:
          type: object
          properties:
            id: { type: integer, example: 1 }
            title: { type: string, example: 'Some title' }
            # ...the whole resource/model, or a generic {type: object, nullable: true}

Expected (per the OpenAPI spec, a 204 response has no body):

responses:
  204:
    description: ''

Root cause

In BaseGenerator::generateEndpointResponsesSpec():

$code = $response->status; // OpenAPI spec requires status codes to be integers
if ($code === '204') {
    // Must not add content for 204
    ...
}

Knuckles\Camel\Extraction\Response::$status is declared as a strictly-typed int (and is cast with (int) in its constructor), so $code is always an int. Comparing it with === against the string '204' is therefore always false.

Note

This branch also includes an unrelated one-line commit removing an unused import in src/Extracting/ParamHelpers.php. It was failing my branch's CI. Happy to drop it from this PR if you'd rather handle it separately.

TZK- added 2 commits August 20, 2026 16:59
$response->status is a strictly-typed int (Knuckles\Camel\Extraction\Response::$status),
but generateEndpointResponsesSpec() compared it against the string '204' with ===. Since
204 === '204' is always false in PHP, the "must not add content for 204" guard never
triggered, so responses tagged 204 (e.g. via #[Response(status: 204)] or
#[ResponseFromApiResource(..., 204)]) still got a full content schema in the generated
OpenAPI spec.

Compare against the int 204 instead, and add a dedicated regression test asserting the
generated 204 response is exactly `{"description": ""}`, with no `content` key at all.
@TZK-
TZK- force-pushed the fix/204-response-content-type-comparison branch from 21452a0 to 46dcada Compare August 20, 2026 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant