This PR fixes an issue which we also face. @jamietanna what do you think about merging it?

Thanks for this - we'll try and get it into the v1.16.0 release, which should be some time in October - things are a bit busy over the next few weeks so not sure how much of my free time I'll be able to give to oapi-codegen - hoping that at some point I can have enough GitHub sponsors to be able to dedicate a full day a week to Open Source!

@ShouheiNishi @bartsmykla mind checking if the changes in #1389 have solved this for you?

@ShouheiNishi @bartsmykla mind checking if the changes in #1389 have solved this for you?

No.
We plan to summarize the problems that exist after the fix.

To confirm, the fix from #1389 hasn't solved all the external reference issues you're affected by?

To confirm, the fix from #1389 hasn't solved all the external reference issues you're affected by?

Yes.

@ShouheiNishi @bartsmykla mind checking if the changes in #1389 have solved this for you?

Unfortunately I cannot test it now as we reworked our flow to overcome this issue (we are cloning external dependencies and combining them in a one file then referencing int locally), but thank you for looking into this!

What about #1253 that had this issue as a requirement?

What about #1253 that had this issue as a requirement?

PR#1253 adds type conversion. In some of the test codes, the process of getting the destination type does not work correctly due to issue #1202, so some test codes will fail.

To confirm, the fix from #1389 hasn't solved all the external reference issues you're affected by?

At least there are still issues like the test cases in this pull request.

Thank you for contributing, and I'm very sorry for taking so long to get to this PR. At this point, the code has changed so much that it's no longer relevant because external ref propagation was fixed in commit ad5eada (Jan 2024). The externalref.go file contains comprehensive functions for ensuring external refs are propagated to all definition types.