-
Notifications
You must be signed in to change notification settings - Fork 2k
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
apollo-server-core 2.9.14 breaks APQ usage #3627
Comments
Having the same issue - we're using APQ ("persisted queries") on the frontend, so all GraphQL queries 'fail' for the first time (because the request is a hash of the query, and not the full query). The recent PT #3614 ensured that these errors show up as exceptions in the request pipeline of Apollo, but seems like error-handling logic should be expanded to... start the timer? Not sure. Our solution was to disable this feature in the frontend app for now. Paging @abernix and @trevor-scheer as APQ & 2.9.14 is currently an unhappy duo :) |
+1 |
Thanks for reporting this! It appears as if this could be related to an unexpected condition within Apollo Engine Reporting (i.e. |
This should be fixed by #3638, which I just released in v2.9.15. |
Thanks @abernix - v2.9.15 fixed it for me. Thank you for such a quick patch over the holidays! |
Thanks for feedback confirming that it’s fixed! |
Hi. Seeing this error again in 2.11.0 It seems to throw even if engine is set to false.
|
@abbashassanali Could you please provide us with a running reproduction? Thank you! cc: @trevor-scheer |
@abbashassanali If anyone can provide a reproduction for this problem, please do so in #3978. Locking this issue to prevent upvotes from accumulating on this closed issue, and rather encourage those up-voters to provide reproduction steps. |
My GraphQL App server depends on apollo-server-express which I recently updated to 2.9.14 (which in turn resolves apollo-server-core 2.9.14). Upon updating to this version, my APQ queries started failing, with an internal error 500 as the response:
My expected response was:
Upon further reading of code, I found this PR that changes the server-core and might be influencing the behavior: dcbbc34
I am not sure if I am doing something wrong on the Apollo Client side, but
A prior release tag of app included 2.9.13 for both apollo-server-express and apollo-server-core works fine. My temp fix involved was to get that package-lock from that tag to ensure that it worked.
Note: Manually edited the error responses for easy reading and to redact private path structures
The text was updated successfully, but these errors were encountered: