d-exclaimation/pioneer

VaporMiddleware responding incorrectly to all paths

Closed this issue · 7 comments

Describe the bug
I have REST in addition to GraphQL, when I try to make a request in REST I get the error "Unable to parse the request and identify the operation. Specify the query string parameter "query" with a GraphQL query". REST is available via the path /api

To Reproduce
Steps to reproduce the behavior:

  1. Add a route for REST
  2. Make a controller for this route
  3. Try to make a request to this route
  4. See error

Expected behavior
I was expecting GraphQL to only work with the graphql path provided in vaporMiddleware, but it handles all requests. Because of this, I cannot get into the routes for REST.

Desktop (please complete the following information):

  • OS: [e.g. MacOS]
  • Version [e.g. 13.2]
  • Pioneer configuration [e.g. introspection: true]

Looks like a bug on my part, I'll have a look and see why the GraphQL Middleware is responding on a different path

Is this happening for both GET and POST request?

Yes

I have an existing simple GraphQL server running and I added some few non-GraphQL routes, I couldn't get Pioneer to respond to any of those non-GraphQL endpoints and reproduce. Can you share a bit more on this bug such as:

  • Some example of the REST endpoints
  • The HTTP method of the request or a sample HTTP request being made
  • Where did you add the VaporMiddleware and is it before or after the REST endpoints where set up
  • What did you pass in in the VaporMiddleware options

Yes

Right, so it's just the middleware somehow ignoring the path

I found what is the problem. I wrote a separate middleware to get a list of fields and further select these fields through Fluent, it accesses graphql in Request and gives an error. For some reason this problem didn't exist before version 1

I found what is the problem. I wrote a separate middleware to get a list of fields and further select these fields through Fluent, it accesses graphql in Request and gives an error. For some reason this problem didn't exist before version 1

I'm glad you managed to resolve the issue.

Version 1 is in fact a bit more strict and verbose on errors from decoding GraphQL Request as to follow all requirements for the GraphQL over HTTP spec.