[BUG] Breaking change in the resolution of relative imports between 4.3.0 and 4.3.1

[Carsten-Leue]

Bug Report Checklist

• [x] Have you provided a full/minimal spec to reproduce the issue?
• [x] Have you validated the input using an OpenAPI validator (example)?
• [x] What's the version of OpenAPI Generator used? 4.3.0 and 4.3.1
• [x] Have you search for related issues/PRs?

Description

My openapi description is decomposed into many files that reference each other via relative paths. The specification can be processed with v4.3.0 (and lower) successfully but the same fails with v4.3.1

openapi-generator version

The error occurs on v4.3.1. It is a regression since the same worked for v4.3.0 and lower.

OpenAPI declaration file content or url

Please check this repo for a minimal testcase since multiple files are involved:

https://github.com/Carsten-Leue/openapi-import-bug

Command line used for generation

successful command

java -jar openapi-generator-cli-4.3.0.jar generate -g openapi -i openapi/index.json -o out/4.3.0/

unsuccessful command

java -jar openapi-generator-cli-4.3.1.jar generate -g openapi -i openapi/index.json -o out/4.3.1/

Steps to reproduce

Checkout https://github.com/Carsten-Leue/openapi-import-bug and execute the run.bat script

[wing328]

@Carsten-Leue thanks for reporting the issue. I wonder if you can use git bisect to identify the commit that breaks your use cases.

[Carsten-Leue]

@wing328 : This is the output of git bisect:

8a12a810d486b8a4c07530bb8cd0548d544ff1d2 is the first bad commit
commit 8a12a810d486b8a4c07530bb8cd0548d544ff1d2
Author: William Cheng <wing328hk@gmail.com>
Date:   Mon Apr 6 00:12:40 2020 +0800

    Update swagger parser to 2.0.19 (#5413)

    * update swagger parser to 2.0.18

    * fix online server exception

    * Revert "fix online server exception"

    This reverts commit fe3cb5221f362c00b176fa81411eaf368f0e446d.

    * update parser to 2.0.19

 pom.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[Carsten-Leue]

@wing328 note that I do not insist in making the generator work with the initial version of my schema file if the new behaviour fixed some inconsistencies. However the new behaviour looks strange, too.

I have added a folder to my example project https://github.com/Carsten-Leue/openapi-import-bug to illustrate this. Check the imports https://github.com/Carsten-Leue/openapi-import-bug/blob/master/openapi_new/containers-by_id_or_name/sub/paths.json#L7 and https://github.com/Carsten-Leue/openapi-import-bug/blob/master/openapi_new/containers-by_id_or_name/sub/paths.json#L32.

the first is

../components/parameters/zaciapi_header.json

the second

../../containers/components/schemas/UpdateContainerRequest.json

However the addressed components and containers folder are siblings. Why do I need to use .. in one case and ../.. in the other case to reference from the same file to the same parent folder structure? This looks inconsistent, I would have expected that the relative URIs are relative to the URI of the including file. The apparent difference is that in one case the $ref is on the level of the openapispec and in the other case on the level of a schema spec. But this should not make a difference in my eyes.

I would expect to use ../.. in both cases.

[wing328]

We've just updated the swagger parser to a newer version. Can you please try the latest master to see if it works better for you?

[Carsten-Leue]

I have pulled from master and retried. Version of swagger parser is 2.0.20 now. Unfortunately the problem is still the same.

What relative import would you actually expect in the previous example? Does the presumed inconsistency really make sense?

[CarstenLeue]

The problem has potentially been introduced by https://github.com/swagger-api/swagger-parser/issues/505