[BUG] debugSupportingFiles no longer works

[spacether]

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 (example)

Description

[BUG] debugSupportingFiles no longer works

openapi-generator version

Latest, may have shown up in 6.2.1 per Slack chat

OpenAPI declaration file content or url

Generation Details

./bin/generate-samples.sh bin/configs/kotlin-spring-boot.yaml -- --global-property debugSupportingFiles=true

Steps to reproduce

Run any generate command with debugSupportingFiles turned on

Related issues/PRs

Suggest a fix

[jlengrand]

I cannot edit this issue, so let me add additional information.

I can consistently reproduce this from master.

Here is the stacktrace when running the command above:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at com.fasterxml.jackson.core.util.TextBuffer.carr(TextBuffer.java:967)
        at com.fasterxml.jackson.core.util.TextBuffer.expand(TextBuffer.java:928)
        at com.fasterxml.jackson.core.util.TextBuffer.append(TextBuffer.java:682)
        at com.fasterxml.jackson.core.io.SegmentedStringWriter.write(SegmentedStringWriter.java:58)
        at com.fasterxml.jackson.core.json.WriterBasedJsonGenerator.writeRaw(WriterBasedJsonGenerator.java:605)
        at com.fasterxml.jackson.core.util.DefaultIndenter.writeIndentation(DefaultIndenter.java:94)
        at com.fasterxml.jackson.core.util.DefaultPrettyPrinter.writeObjectEntrySeparator(DefaultPrettyPrinter.java:332)
        at com.fasterxml.jackson.core.json.WriterBasedJsonGenerator._writePPFieldName(WriterBasedJsonGenerator.java:382)
        at com.fasterxml.jackson.core.json.WriterBasedJsonGenerator._writeFieldName(WriterBasedJsonGenerator.java:196)
        at com.fasterxml.jackson.core.json.WriterBasedJsonGenerator.writeFieldName(WriterBasedJsonGenerator.java:161)
        at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:726)
        at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:774)
        at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:178)
        at com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serializeContents(IndexedListSerializer.java:119)
        at com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:79)
        at com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:18)
        at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:728)
        at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:774)
        at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:178)
        at com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serializeContents(IndexedListSerializer.java:119)
        at com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:79)
        at com.fasterxml.jackson.databind.ser.impl.IndexedListSerializer.serialize(IndexedListSerializer.java:18)
        at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:728)
        at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:774)
        at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:178)
        at com.fasterxml.jackson.databind.ser.std.MapSerializer.serializeOptionalFields(MapSerializer.java:869)
        at com.fasterxml.jackson.databind.ser.std.MapSerializer.serializeWithoutTypeInfo(MapSerializer.java:760)
        at com.fasterxml.jackson.databind.ser.std.MapSerializer.serialize(MapSerializer.java:720)
        at com.fasterxml.jackson.databind.ser.std.MapSerializer.serialize(MapSerializer.java:35)
        at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:728)
        at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:774)
        at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:178)

Looking at it, it looks like the issue comes from this line :

        if (GlobalSettings.getProperty("debugSupportingFiles") != null) {
            LOGGER.info("############ Supporting file info ############");
            Json.prettyPrint(bundle);
        }

as in, bundle fails to go through the JSON parser. Maybe because of an infinite loop?

Note that pretty printing works for operation or models so it seems quite a specific issue.

I can reproduce consistently on all configs I try, so it seems that the problem is not localized. Examples :

$  ./bin/generate-samples.sh bin/configs/ruby.yaml -- --global-property debugSupportingFiles=true
$ ./bin/generate-samples.sh bin/configs/java-vertx.yaml -- --global-property debugSupportingFiles=true
...

System is a Mac OS Ventura running openjdk 17.0.2 2022-01-18.

Tried playing with -Xms and -Xmx to outrageous values lead to nothing.

[jlengrand]

I can reproduce the same issue with v6.1.0, v6.0.0, and even v5.4.0. Looks like I either have a tricky system, or I am the only one using that option ^^

[jlengrand]

Alright, been using $git bisect with the following configuration :

generate -g kotlin -i modules/openapi-generator/src/test/resources/3_0/petstore.yaml -o samples/client/petstore/kotlin/http/client --global-property debugSupportingFiles

(Couldn't use generate-samples because the bug was introduced before this script was created :)).

It appears the bug was introduced in ef8e55ca21d71dd1e68c47ea239974c75b96a4f8.

[jlengrand]

Alright, diving further, the error goes away if I comment out that part of the CodegenOperation file :

    /**
     * @return contentTypeToOperation
     * returns a map where the key is the request body content type and the value is the current CodegenOperation
     * this is needed by templates when a different signature is needed for each request body content type
     */
    public Map<String, CodegenOperation> getContentTypeToOperation() {
        LinkedHashMap<String, CodegenOperation> contentTypeToOperation = new LinkedHashMap<>();
        if (bodyParam == null) {
            return null;
        }
        LinkedHashMap<String, CodegenMediaType> content = bodyParam.getContent();
//        for (String contentType: content.keySet()) {
 //           contentTypeToOperation.put(contentType, this);
  //      }
        return contentTypeToOperation;
    }

ef8e55c#diff-8b968986cd609d4ff488d18da27a0a46020d12478584614d625ff7b4640fb4d8R211

[jlengrand]

Ok, I think I understand what happens.
Here's what the output of contentTypeToOperation looks like for me when debugging :

As I understand it, it basically contains the whole operation again in different formats, leading to infinite loops when asking to JSON.print the structure further down the line.

I'd appreciate some advice at this point. Can someone confirm the problem and offer a potential solution?

Should we

• Ignore this part when JSON.printing so we avoid the recursion
• Transform the Map to a LinkedHashMap<String, String>, in the different formats?
• Something else?

Thanks!

[spacether]

Ignore this part when JSON.printing so we avoid the recursion

Thanks for doing this research. This is the preferred solution. Want to fix it in a PR?

[jlengrand]

Hey there,

I'll give a stab at it! Though not exactly sure how, given the method is called by the Object.toString method deep inside the JSON library, and not present in the bundle in the first place. I'll call for help if needed!

[jlengrand]

Created #14266 to propose a fix.

[jlengrand]

🎉

[jlengrand]

I think this can be closed @spacether @wing328 ? Or are you folks waiting for a version release? (happy new year in advance BTW!)

[spacether]

This issue was fixed in #14298