Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • O openapi-generator
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,476
    • Issues 3,476
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 402
    • Merge requests 402
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OpenAPI Tools
  • openapi-generator
  • Issues
  • #7712
Closed
Open
Issue created Oct 14, 2020 by Administrator@rootContributor4 of 4 checklist items completed4/4 checklist items

[BUG][PHP] DateTime in query param passes DateTime object to Guzzle, causing error

Created by: jaydiablo

Bug Report Checklist

  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator (example)?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
Description

In this pull request (https://github.com/OpenAPITools/openapi-generator/pull/3984) the way that query params are parsed changed. Specifically this change:

https://github.com/OpenAPITools/openapi-generator/pull/3984/files#diff-f8be3e87599b0a25a849609b1492f754c182111899b3c86f3497504fb9f60b8aL482

By removing ObjectSerializer::toQueryValue DateTime objects are not converted to a string (toQueryValue calls toString on the input). This results in the DateTime object being passed to Guzzle, which results in this warning being issued (from this call https://github.com/guzzle/psr7/blob/1.6.1/src/functions.php#L600):

rawurlencode() expects parameter 1 to be string, object given

And then null is returned:

https://3v4l.org/AOU5T

I've confirmed that master still contains the same template that was introduced in #3984: https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/php/api.mustache#L474-L501

openapi-generator version

This first shows up in 4.3.0, reverting to 4.2.3 fixes it.

OpenAPI declaration file content or url

A sample param in an OpenAPI 2.0 config like this will trigger this generation:

{
    "name": "date",
    "in": "query",
    "description": "date filter",
    "required": false,
    "type": "string",
    "default": "",
    "format": "date"
}
Generation Details

I don't think this is relevant, but generating with this command:

./node_modules/.bin/openapi-generator-cli generate -i ./schema/openapi.json -g php -o ./ -c openapi-generator-config.json

openapi-generator-config.json resembles something like this:

{
    "variableNamingConvention": "camelCase",
    "srcBasePath": "src",
    "packageName": "package",
    "invokerPackage": "package",
    "apiPackage": "Api",
    "modelPackage": "Model"
}
Steps to reproduce

Generating a PHP client from an OpenAPI file (in our case it's OpenAPI 2.0, but as I understand the templates, it will happen with any version that OpenAPI generator supports) that has a "date" or "date-time" formatted query parameter definition will encounter this issue. The petstore example API has some "date" and "date-time" parameters, but they're form parameters, not query parameters, so this issue doesn't show up in those examples.

Suggest a fix

I think that non-collection query parameters still need to be passed through ObjectSerializer::toQueryValue so that toString is called on DateTime objects. I'm not sure how that impacts what #3984 was trying to fix though.

Assignee
Assign to
Time tracking