Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERR_INVALID_URL: Regression OpenAPIv3 sources require servers attribute #4416

Closed
4 tasks
JustusNBB opened this issue Sep 1, 2022 · 5 comments
Closed
4 tasks

Comments

@JustusNBB
Copy link
Contributor

JustusNBB commented Sep 1, 2022

Issue workflow progress

Progress of the issue based on the Contributor Workflow

Make sure to fork this template and run yarn generate in the terminal.

Please make sure Mesh package versions under package.json matches yours.

  • 2. A failing test has been provided
  • 3. A local solution has been provided
  • 4. A pull request is pending review

Describe the bug
After upgrading dependencies, my mesh throws ERR_INVALID_URL, because no baseUrl, host or servers is given.
Previously it was enough to load the schema with an absolute SourceURL and it would configure itself with that host as baseUrl using that source!

To Reproduce
Steps to reproduce the behavior:
Use an OpenAPIv3 Swagger Schema without servers (host+basePath) config.

I can't trim this down to a simple sandbox yet, too many open questions.

Results in this kind of error:

TypeError [ERR_INVALID_URL]: Invalid URL: api/v1/route_whatever/arg
or
TypeError: Only absolute URLs are supported

Expected behavior

Somehow this is still working with older graphql-mesh versions, there the host is derived from the sourceUrl I guess... I would expect something alike this to be implemented again.

How should multiple server hosts be handled?
The upstream source uses OpenAPIv3, which may expose servers instead of host & baseUrl, but that is optional.

Environment:

  • OS: Windows/Ubuntu
  • @graphql-mesh/cli: 0.76.2
  • @graphql-mesh/openapi: 0.32.1
  • NodeJS: 14

Additional context
Also I noticed newly imported snake_casing, there are quite a few changes concerning the OpenAPI Handler including WIP Overhaul: #4278, I am still missing overview as it is a bit much, what recent changes did I miss?
The OpenAPI Handler Migration for v0.32 did not affect me - I think.

I was able to use the latest packages with a bit of manual tinkering (fixing type issues):
How can I workaround this?
Providing a baseUrl override in the .meshrc.yml seems to do the trick! But that still confuses me, why is it needed now?

What happend to Swagger Schema Integrity Validation? It seems json-machete does not implement that anymore, what's the background?

@ardatan
Copy link
Owner

ardatan commented Sep 1, 2022

Also I noticed newly imported snake_casing, there are quite a few changes concerning the OpenAPI Handler including WIP

Snake casing is not imported. In contrast, we no longer apply naming convention like the old version.

what recent changes did I miss?

All changes can be found in the change logs and the migration guide.

I was able to use the latest packages with a bit of manual tinkering (fixing type issues):

What do you mean by type issues?

What happend to Swagger Schema Integrity Validation? It seems json-machete does not implement that anymore, what's the background?

We don't validate OpenAPI schemas anymore, it is user's responsibility to provide a valid schema in the new approach.

After upgrading dependencies, my mesh throws ERR_INVALID_URL, because no baseUrl, host or servers is given.
Previously it was enough to load the schema with an absolute SourceURL and it would configure itself with that host as baseUrl using that source!

We need a reproduction as described in the issue template as always :) Please help us with that so we can help you and improve Mesh together.

@JustusNBB
Copy link
Contributor Author

JustusNBB commented Sep 1, 2022

We need a reproduction as described in the issue template as always :) Please help us with that so we can help you and improve Mesh together.

I am working on that, but it might take a few days to provide this.
Thank you for clearing some of my questions!!

@JustusNBB
Copy link
Contributor Author

Sorry I am having issues to provide a reproduction, it seems to be a bit overkill from my side to fiddle with sandboxes for long hours just for this...

Let's discuss my idea for sandbox reproduction first:

  1. Create a mockup API with simple OpenAPIv3 schema without servers, host and baseUrl attributes (simple file mockup is insufficient) - reuse one of the examples?!
  2. Create two sandboxes with new and old versions of the OpenAPI handler - meshrc should only contain a single sourceUrl
  3. Boot up mockup alongside playground in the sandbox and try to query somthing through graphiql
  • sandbox with old version will not throw INVALID_URL
  • sandbox with latest version can be fixed by adding a baseUrl, as a workaround

@ardatan
Copy link
Owner

ardatan commented Sep 2, 2022

@JustusNBB I checked our implementation and couldn't find when the base url is used during the schema generation.
We already have fixtures that don't include any servers definition in our tests. So it is not reproducible with the information you gave so far. That's why I need a reproduction to see what's happening by debugging in a more straight forward way, because our conversation doesn't go anywhere apparently.

https://github.com/Urigo/graphql-mesh/blob/master/packages/loaders/openapi/tests/fixtures/basket.json

@JustusNBB
Copy link
Contributor Author

I checked our implementation and couldn't find when the base url is used during the schema generation.

But I ment for the host part inside sourceUrl to be used at runtime as a baseUrl fallback, that is maybe something that we had before and now needs to be explicitly set.

I think we should actually close, because I have most of the information I need and can't give reproduction priority while already having a workaround/fix.

Unlikely that I will reopen myself (because of priority and time constraints).
I will however open another ticket for a weird minor issue I discovered with the Type Generation.

Keep up the great work and insanely fast response times!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants