[BUG][PYTHON] BOUNTY Unwanted string-to-date coercion in allOf

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?
• What’s the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request: $250 $1,000 (see below!)

Description

Using -g python on a spec that has a schema item with a string value, it’s usually an integer but it doesn’t have to be. When it’s an integer that can be parsed as a date, it gets turned into a date. Sometimes. The way I’ve been able to consistently replicate it is with a composite object using allOf.

In the spec below, there are two schemas called thingone and thingtwo, each an object with two string properties, and another schema called twothings which is an allOf composition of thingone and thingtwo. When processing a twothings response, where all the string properties are of the form YYYYMMDD, the string properties that belong to thingone are coerced into dates.

openapi-generator version

5.3.1-SNAPSHOT using Docker

OpenAPI declaration file content or url

https://gist.github.com/mariodsantana/9944ee3e4d669771bccaeb059ce863a0

Generation Details

docker run -u $UID --rm -v $PWD:/local openapitools/openapi-generator-cli \
    generate -i /local/openapi.yaml -g python -o /local \
    --additional-properties packageName=fake \
    --additional-properties pythonAttrNoneIfUnset=true \
    --additional-properties generateSourceCodeOnly=true

Steps to reproduce

1. Copy the openapi spec below
2. Generate client code
3. Run mocking server
4. Call the get_twothings API
5. Notice that some of the results are dates

I’ve written a little bash script to do all of the above, see https://gist.github.com/mariodsantana/28477b908e0d50e17cbcddb52161d790

Related issues/PRs

Obviously there’s a lot of work going on with composed schemas and allOf &co, but in my ignorance I couldn’t find anything that seemed actually related to this.

Suggest a fix

No real idea. I can fix the immediate issue with a small patch to the generated model_utils.py but then that keeps legitimate dates from being converted from strings.

I’m willing to sponsor this work to the tune of $250. Maybe more if it turns out to be a complicated issue. ETA: It’s turned out to be a complicated issue. I’ve upped the bounty to $1,000. 😃

[spacether]

I am working on a new version of the python generator which will not have this issue. This bug arises because values are coerced from one type into another. That’s not what openapi/jsonschema intends. Jsonschema/openapi is a domain specific language specifying type and validation constraints. In my new python-experimental generator data is validated but it is not coerced from one type to another. Specifically for date and datetime data, the data is stored as a string and there are date and datetime accessor methods. The only exceptions on coercion in python-expeirmental will be:

• serializing schema data into string-transmitted endpoint parameters like header, path, cookie, query parameters
• deserializing headers into schema data (data starts out as string data and would need to be coerced into non-string types like int/float etc)

I intend on releasing it soon.

[mariodsantana]

@spacether - I’m not sure when I’ll get the time to refactor my spec to make use of (and test) your changes. I’ve made you wait too long as it is. DM inbound to discuss bounty payment details. Thanks for your work, and apologies for the delay!