-
-
Notifications
You must be signed in to change notification settings - Fork 516
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
Non-GraphQL requests with 'query' in URL params fail with AbortError #489
Comments
Hey, @LukeTillman. Thank you for reaching out. You're right, currently In the case of an application that combines both REST and GraphQL API mocking, I'd highly recommend scoping the GraphQL handlers to an exact endpoint via import { graphql } from 'msw'
const api = graphql.link('https://api.backend.com/graphql') That being said, I see that at the moment the parsing step precedes the URL matching step: Lines 175 to 182 in 8a5f573
Which still makes such use cases as yours to happen. I think you are correct in assuming that we should handle parsing exceptions gracefully for both GraphQL and non-GraphQL requests. We may even consider doing this on the response retrieval step: Lines 38 to 47 in 8a5f573
Do you see any implications if we do so? Fundamentally, there's an issue of finding a reliable way to determine a request is a GraphQL API request. I don't think that silencing the query parsing exception is the best solution, as that cuts off a debugging aspect. However, with the lack of a better way to distinguish between GraphQL and non-GraphQL requests that may be the most optimal decision. |
Hey @kettanaito, thanks for the quick response. I have two thoughts:
As far as I know, there really isn't any more reliable way to tell whether a request is meant as a GraphQL API request. I think if the you kept that logic (i.e. looking for a
For our GraphQL server (written in Go), parsing errors or malformed requests (e.g. querying a field that doesn't exist in GraphQL schema, etc.) usually return a 400 Bad Request along with a JSON payload that gives the error details. |
Thank you for the feedback, @LukeTillman.
That is a good idea, but without a reliable way to know if the request was to a GraphQL API, we won't know when to respond with the parsing error. We don't want to respond to a seemingly matching REST API request with a GraphQL parsing error, that may be confusing. However, compared to the silent swallowing of the parsing error, it would be preferable to return a 400 response with a parsing error, surfacing the issue to the developer. Technically, we don't have a way to respond amidst the request handler execution at the moment. We'd have to consider if this is really needed, or another technical way to surface the parsing error. |
Yeah, agreed you don't want to return a parsing error for GraphQL to a REST request, but definitely would make it more obvious what's going on. You could also potentially "enhance" the error message that comes back in the payload to maybe give more information, maybe pointing to If you wanted to make a larger change, long-term you could make using |
@kettanaito Just saw the label and I'm happy to help contribute a PR if we've settled on an approach. It wasn't clear to me if we had, yet. |
@LukeTillman I've just started on a PR over in #513 that touches some of these same things. I haven't handled this specific case yet as I just saw this issue, but perhaps both things can be addressed there. I ran into the exact issue that's being described here though, and left random thoughts about how things are processed as I was going. I was thinking about the same process you're describing with enforcing |
Hey, @kettanaito
Does it make sense to break out the part of the Lines 33 to 47 in 8a5f573
So that |
Hi, @pa3. Yes, that's a valid suggestion. We are currently reworking the request handler API (#561) and it will run the list of handlers exactly as you've described:
With those changes, |
Sounds awesome! Thanks a ton for explanation, @kettanaito! |
Describe the bug
We have a setup where we talk to both a GraphQL API and some REST APIs as well, thus our server instance has both types of request handlers. If you make a regular REST request with
?query=some-not-graphql-value
in the URL params and your server also has GraphQL request handlers, the first GraphQL handler will attempt to parse the request, which will fail and cause the request to error out.For us, this was manifesting as
AbortError: Aborted
on those requests because it looks like the interceptor library aborts any requests where middleware throws errors. The underlying error causing it to abort the requests is a GraphQL syntax error when trying to parse:GraphQLError: Syntax Error: Unexpected Name ...
.We were getting this from
GET
requests, but after tracing through the code, I think the same is probably true if you tried it withPOST
and hadquery
in the request body that was not a GraphQL query. We saw this behavior using the Node server in Jest unit tests.Environment
msw: 0.20.5
nodejs: 14.4.0
To Reproduce
Steps to reproduce the behavior:
.use
any GraphQL request handler (e.g. in Jest).GET
request to a URL with?query=not-graphql
in the URL.Expected behavior
The request shouldn't fail in this case, although I'm unsure of what the correct fix is. It could be as simple as just doing a
try...catch
around parsing and then just returningnull
so that processing moves on to the next handler if parsing fails. If the "predicate" step (i.e. URL matching I think?) happened before parsing, it would probably be possible for us to workaround it by specifying a URL for our GraphQL endpoint (i.e. usegraphql.link
) so that those GraphQL handlers wouldn't try to parse the request at all.Happy to help with a PR or however I can.
The text was updated successfully, but these errors were encountered: