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.

@greptileai

Greptile Summary

This PR implements a multi-pass type name resolution system to handle collisions across OpenAPI component sections and client response wrappers. The implementation splits code generation into two phases: gathering all schemas with location metadata, then globally resolving naming conflicts using iterative strategies (context suffix, per-schema disambiguation, numeric fallback). Component schemas are privileged and keep bare names when colliding with other types.

Key improvements:

• New gather.go walks the entire spec collecting schemas with context metadata
• New resolve_names.go assigns unique names via multi-phase collision resolution
• Client response wrapper types now participate in collision detection
• Removed deprecated ComponentType and FixDuplicateTypeNames functions
• Fixed multi-content-type response handling to prevent duplicate/conflicting inline type declarations
• Comprehensive test coverage with patterns from 13+ issues

The feature is gated behind the existing resolve-type-name-collisions flag (default false), ensuring no behavior change unless explicitly enabled. All existing tests pass without modification.

Confidence Score: 4/5

• This PR is safe to merge with careful attention to the multi-content-type handling logic
• The implementation is well-architected with comprehensive test coverage. Recent commits fixed critical issues with multi-content-type responses. The feature is opt-in, maintaining backward compatibility. Score is 4 (not 5) due to complexity of the multi-content-type path handling and potential edge cases around the prefix matching fallback in resolvedNameForComponent
• Pay close attention to pkg/codegen/codegen.go and pkg/codegen/operations.go where multi-content-type response handling was recently fixed

_{Last reviewed commit: dd19a4e}

Yeah, you're right. This code path ignores the name overrides and the name normalizer function. It's an oversight on my part.

I'm going to change it so that user provided names are "pinned", even if that causes conflict, we don't want to second-guess them, but other names will change around them.

Fixing the initialisms is easy. Another update, with test coverage for all these scenarios, is coming soon.

I've regenerated what this looks like as on-by-default and the changes look good, as well as with rootly-go, thanks!