Skip to content

[BUG] [PHP Symfony] Impossible to handle endpoints with "text/plain" or "image/png" response type #21256

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
5 of 6 tasks
gturri opened this issue May 9, 2025 · 0 comments · Fixed by #21261
Closed
5 of 6 tasks

Comments

@gturri
Copy link
Contributor

gturri commented May 9, 2025

Bug Report Checklist

  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
  • [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description
openapi-generator version

I tested with 7.12.0 and also with the latest master

OpenAPI declaration file content or url

This has 5 endpoints. Each of those endpoint illustrates the issue, but each with a different return type (so the fix can be tested against each)

openapi: 3.0.3
info:
  title: repro issue openapi-generator
  version: 0.0.1
paths:
  /get-bool:
    get:
      summary: get a boolean
      responses:
        "200":
          description: OK
          content:
            text/plain:
              schema:
                type: boolean
  /get-image:
    get:
      summary: get an image
      responses:
        "200":
          description: OK
          content:
            image/png:
              schema:
                type: string
                format: binary
  /get-string:
    get:
      summary: get a string
      responses:
        "200":
          description: OK
          content:
            text/plain:
              schema:
                type: string
  /get-int:
    get:
      summary: get an int
      responses:
        "200":
          description: OK
          content:
            text/plain:
              schema:
                type: integer
  /get-number:
    get:
      summary: get a number
      responses:
        "200":
          description: OK
          content:
            text/plain:
              schema:
                type: number

Generation Details

java -jar openapi-generator-cli.jar generate --git-user-id "some-user" --git-repo-id "some-project" -i "openapi.yaml" -g php-symfony -o "generated"

Steps to reproduce

Implement a simple symfony controller like this:

<?php
namespace App\Controller;

use OpenAPI\Server\Api\DefaultApiInterface;
use Endroid\QrCode\Builder\Builder;
use Endroid\QrCode\Writer\PngWriter;

class DefaultApi implements DefaultApiInterface {
    public function getBoolGet(int &$responseCode, array &$responseHeaders): array|object|null {
      return true;
    }

    // I'm using composer package "endroid/qr-code" to generate a png
    public function getImageGet(int &$responseCode, array &$responseHeaders): array|object|null {
		$builder = new Builder(writer: new PngWriter(), data: "some qr code");
		return $builder->build()->getString();
    }

    public function getIntGet(int &$responseCode, array &$responseHeaders): array|object|null {
        return 1312;
    }

    public function getNumberGet(int &$responseCode, array &$responseHeaders): array|object|null {
        return 13.12;
    }

    public function getStringGet(int &$responseCode, array &$responseHeaders): array|object|null {
        return "hello world!";
    }
}

then try to query any of those endpoints.

The generated code replies with a 406 instead of the expected response. (But there are actually 3 issues, and the 406 is just the first one that reveals itself. More details below).

Related issues/PRs

This is bit similar to #13334 but this report is more generic because #13334 identifies only one of the three actual issues (see below).
Similarly the open PR #15560 tries to address part of the issue, but it's only a partial fix of one of the issue

Suggest a fix

There are 3 things that needs to be fixed:

  • The generated method Controller.getOutputFormat should be able to return more type than just application/json or application/xml (that's the reason why we have a 406)
  • The generated methods of DefaultController should properly define the expected return type (see snippet above: what I return does not match array|object|null). This should be done by handling those other types in PhpSymfonyServerCodegen.java in the method postProcessOperationsWIthModels, when x-return-type is set
  • in JmsSerializer.serialize it should not try to call ->serialize($data, ...) when the 2nd argument is null, otherwise it crashes at runtime (error 500) because the type of that 2nd argument is declared to be a string.

I'm going to submit shortly a PR that implements those 3 fixes

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