Skip to content
This repository was archived by the owner on Dec 25, 2024. It is now read-only.

[BUG][PYTHON] $ref to remote url is failing with v2.0.0 and higher #341

Closed
3 of 6 tasks
BaptisteSaves opened this issue Dec 20, 2023 · 6 comments
Closed
3 of 6 tasks

Comments

@BaptisteSaves
Copy link

BaptisteSaves commented Dec 20, 2023

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
Description

When using an http reference, the generator fails with error [main] WARN org.openapijsonschematools.codegen.common.ModelUtils - Failed to get the schema at $ref:

Is using an http $ref supported by the generator ?

Bonus point:
Some of our http ref have local reference ./XXX.yaml that also needs to be followed.

openapi-json-schema-generator version

3.3.1

OpenAPI declaration file content or url
$ref: https://XXX.yaml`
Generation Details

docker run --rm -v ./:/local openapijsonschematools/openapi-json-schema-generator-cli:3.3.1 generate -i /local/my-service.yml -g python -o /local/out

Steps to reproduce

Generate the client with a ref to an http yaml

Suggest a fix

The getSimpleRef seems to return null for any http $ref


And I haven't found any place where the referenced file would be downloaded.

@spacether
Copy link
Contributor

spacether commented Dec 20, 2023

This is happening because it is the parsers job to get remote refs and local file refs. I turned ref resolving off to preserve refs inside openapi documents from one place to another. This could be fixed by

  • parsing the openapi document twice with swagger-parser
  • once as it is now
  • and the other time with resolve refs on
  • then iterate through the first parsed schemas and any refs outside the document should be replaced with results from the second parsing

Is this something that you want to fix?

In the meantime you can produce one openapi document with redlocity cli and use that output as the openapi document input for my tool.
https://github.com/Redocly/redocly-cli
And their command is bundle

@BaptisteSaves
Copy link
Author

Thanks for the quick answer 🙏

Is this something that you want to fix?

I tried to understand the code to see if there was a quick fix to do. So far I am struggling to understand how this work and I do not think I have the time or capacity to deliver a fix of this amplitude

@spacether
Copy link
Contributor

Are you open to using redlocity cli to pre process your openapi document and bundle it into one output openapi document?

@BaptisteSaves
Copy link
Author

BaptisteSaves commented Dec 20, 2023

It feels strange that this is not supported in v3 as we were using it in v1.0.4.

Yes, it seems at first glance that using redocly-cli as a pre step could work for us :)

@spacether
Copy link
Contributor

spacether commented Dec 20, 2023

Glad to hear that preprocessing could work for you.

Turning ref resolving on resulted in overly aggressive resolution of refs where some refs to components were resolved rather than preserving the ref to the component. So I turned it off because it broke functionality and there is not enough fine grained control of the ref resolution in swagger parser. When I added support for component responses in v2.0.0 I ran in to this issue and made the change.

One can see a swagger-parser bug on this issue here

@spacether spacether changed the title [BUG][PYTHON] $ref on remote url is failing [BUG][PYTHON] $ref to remote url is failing with v2.0.0 and higher Dec 23, 2023
@BaptisteSaves
Copy link
Author

@spacether Should we close this issue as not planned ?

@spacether spacether closed this as not planned Won't fix, can't repro, duplicate, stale Dec 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants