usage reporting: don't throw errors if willResolveField is called "late" #6398
Conversation
✅ Deploy Preview for apollo-server-docs canceled.
|
|
I know I wrote a lot of details in this comment but I'm not sure that it's particularly clear. |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 3fd72b1:
|
There was a problem hiding this comment.
LGTM and the "confusing" comment actually explains the issue perfectly. And thanks for including the relevant graphql PR, I subscribed so we can follow along and hopefully go back to throwing an error in the future!
Include PR number as well in the changelog maybe?
The comment explains this in detail. Basically, this "shouldn't happen" error actually could happen. In theory, the times it could happen are the exact times that the error itself would be swallowed rather than becoming visible... but a graphql-js bug meant that sometimes they would become visible anyway. Fixes #4472.
glasser
force-pushed
the
glasser/willresolvefield-after-stoptiming
branch
from
c555f27 to
3fd72b1
Compare
|
Would you fine humans be open to a PR back-porting this to |
|
No, Apollo Server v2 is no longer maintained other than for security issues. AS3 was released exactly a year ago today, and we're getting near to v4. It's time to upgrade! |
|
Oh I agree :) I work on a large federated graph and it's hard to compel disparate sub-graph teams to upgrade to a new major version. So it goes. |
The comment explains this in detail. Basically, this "shouldn't happen"
error actually could happen. In theory, the times it could happen are
the exact times that the error itself would be swallowed rather than
becoming visible... but a graphql-js bug meant that sometimes they would
become visible anyway.
Fixes #4472.