Hello!
I tested this branch against the TMF622 ProductOrdering v5.0.0 spec with resolve-type-name-collisions: true and hit the following error:

error generating code: error generating type definitions: error generating code for type definitions:
duplicate typename 'ProductOrderMVORequestBodyJSONRequestBodyJSONRequestBodyJSONRequestBodyJSONRequestBodyJSON'
detected, can't auto-rename, please use x-go-name to specify your own name for one of them

The TMF spec defines ProductOrder_MVO in both components/schemas and components/requestBodies.

The requestBody variant has multiple content types:

• application/json
• application/merge-patch+json
• application/json-patch+json
• application/json-patch-query+json

These are all valid, standardized media types.
The +json structured syntax suffix is also valid.

The problem is in contentTypeSuffix() it uses strings.Contains(ct, "json")
which matches all four types and maps them all to the same "JSON" suffix:

case strings.Contains(ct, "json"):
    return "JSON"

This causes a loop in resolveCollisions.

I think using exact matches for the common media types instead of substring matching,
letting the +json subtypes fall through to mediaTypeToCamelCase, is a better way to go:

func contentTypeSuffix(ct string) string {
    if ct == "" {
        return ""
    }
    ct = strings.ToLower(ct)
    switch ct {
    case "application/json":
        return "JSON"
    case "application/xml", "text/xml":
        return "XML"
    case "application/x-www-form-urlencoded", "multipart/form-data":
        return "Form"
    case "text/plain":
        return "Text"
    case "application/octet-stream":
        return "Binary"
    case "application/yaml", "application/x-yaml":
        return "YAML"
    default:
        return mediaTypeToCamelCase(ct)
    }
}

Additionally, I think strategyContextSuffix should track whether a context suffix has already been applied to prevent the loop.

What do you think about that? Thank you for your work!

Thank you for finding this. i will add it to my test cases.

I'm trying my best to make these changes without breaking backward compatibility, and if I CamelCase-convert the full media type, it's going to change the code generation output for existing users who might not expect their JSON suffix to change to MergePatchJSON or something.

I'm back-porting these fixes from an experiment that I am doing, and I think the only thing I can really do is delegate the choice of converting the full media type to a short name to the user via configuration options.

Look here at the documentation for content-type-short-names configuration option:
https://github.com/oapi-codegen/oapi-codegen-exp/blob/main/experimental/Configuration.md

Whenever I make what I think are simple test cases that are representative, people in the real world have more complex usage :) I never really thought about returning multiple JSON models from a single API.

Ah okay, the content-type-short-names declaration could also work, looks promising.

Trying to fix that issue from above highlighted more issues I briefly described in my PR on your fork here: mromaszewicz#1

Thanks for doing that. This code, as is, should resolve your conflict by appending numerical suffixes to the end after all the collisions.

I think I'm doing the multi-pass wrong. Each strategy needs to be applied globally over all schemas before trying the next one.

@mitsaucepls , please try this latest patch on your schema. I've added your specific example as a test case, and it now works. When, after all rounds of conflict resolution fail, the numeric fallback catches this, and you end up with 1 and 2 suffixes on the conflicting types.

The problem was that you can't try conflict resolution strategies on each conflict group, you must run each strategy globally until it makes no more changes, before moving onto the next one. When you rename things in one conflict group, you may actually rename them into conflict with another schema.

This problem is very, very complicated, which is why I avoided it until now. Thanks for those PR's you are sending, but they're not the right fix for the issue because they can put the new names into conflict with other stuff.

This PR doesn't contain the short names map, that will be a separate pull request which will let you avoid the numerical suffixes and replace them with more meaningful content type abbreviations.

Hey, it definitely generates now! But there are still errors because of undefined types.

I found that helper types are not generated and that causes the undefined type behavior.
So in my case only Responses are affected. I changed the following and all my errors were resolved.

diff --git a/pkg/codegen/codegen.go b/pkg/codegen/codegen.go
index 279ed9d..437af32 100644
--- a/pkg/codegen/codegen.go
+++ b/pkg/codegen/codegen.go
@@ -695,6 +695,7 @@ func GenerateTypesForResponses(t *template.Template, responses openapi3.Response
                        }

                        types = append(types, typeDef)
+                       types = append(types, goType.AdditionalTypes...)
                }
        }
        return types, nil

Without knowing I can imagine other GenerateTypesFor... functions are also affected, just not in my specific case.

Thanks @mitsaucepls . You found another old issue. Neither Responses or RequestBodies handle the additional types, so they miss generating some models.

Please try it again. If that spec continues to have problems, could you attach it here? I couldn't find the OpenAPI file to download.

I just realized I was on main for my last testing... sorry :D

This is the OpenAPI Yaml file Ive been using. TMF622-ProductOrdering-v5.0.0.oas.yaml alternatively downloadable here but it requires an account.

This is the config.yaml I used so far:

package: api
generate:
  echo-server: true
  strict-server: true
  models: true
output-options:
  resolve-type-name-collisions: true
output: gen.api.go

When using the fix/name-collisions branch there are still some errors. But fewer than before!
And on main there are, with the AdditionalTypes fix, none anymore.

I'm going to split that AdditionalTypes fix out of this PR and into a new one, with a new issue, because they are independent problems.

Man, that spec you attached is a doozy. It exposed a few more issues. Now, it generates cleanly with the latest update.