@apollo/server - npm Package Compare versions

Comparing version 4.9.3 to 4.9.4

dist/cjs/generated/packageVersion.d.ts

@@ -1,2 +0,2 @@
-export declare const packageVersion = "4.9.3";
+export declare const packageVersion = "4.9.4";
 //# sourceMappingURL=packageVersion.d.ts.map

dist/cjs/generated/packageVersion.js

 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.packageVersion = void 0;
-exports.packageVersion = "4.9.3";
+exports.packageVersion = "4.9.4";
 //# sourceMappingURL=packageVersion.js.map

dist/cjs/plugin/traceTreeBuilder.js

@@ -63,3 +63,3 @@ "use strict";
         if (this.stopped) {
-            throw internalError('willResolveField called after stopTiming!');
+            return () => { };
         }
@@ -66,0 +66,0 @@ const path = info.path;

dist/esm/generated/packageVersion.d.ts

@@ -1,2 +0,2 @@
-export declare const packageVersion = "4.9.3";
+export declare const packageVersion = "4.9.4";
 //# sourceMappingURL=packageVersion.d.ts.map

dist/esm/generated/packageVersion.js

@@ -1,2 +0,2 @@
-export const packageVersion = "4.9.3";
+export const packageVersion = "4.9.4";
 //# sourceMappingURL=packageVersion.js.map

dist/esm/plugin/traceTreeBuilder.js

@@ -60,3 +60,3 @@ import { GraphQLError, } from 'graphql';
         if (this.stopped) {
-            throw internalError('willResolveField called after stopTiming!');
+            return () => { };
         }
@@ -63,0 +63,0 @@ const path = info.path;

package.json

 {
   "name": "@apollo/server",
-  "version": "4.9.3",
+  "version": "4.9.4",
   "description": "Core engine for Apollo GraphQL server",
@@ -5,0 +5,0 @@ "type": "module",

src/generated/packageVersion.ts

@@ -1,1 +0,1 @@
-export const packageVersion = "4.9.3";
+export const packageVersion = "4.9.4";

src/plugin/traceTreeBuilder.ts

@@ -88,3 +88,45 @@ // This class is a helper for ApolloServerPluginUsageReporting and
     if (this.stopped) {
-      throw internalError('willResolveField called after stopTiming!');
+      // We've been stopped, which means execution is done... and yet we're
+      // still resolving more fields? How can that be? Shouldn't we throw an
+      // error or something?
+      //
+      // Well... we used to do exactly that. But this "shouldn't happen" error
+      // showed up in practice! Turns out that graphql-js can actually continue
+      // to execute more fields indefinitely long after `execute()` resolves!
+      // That's because parallelism on a selection set is implemented using
+      // `Promise.all`, and as soon as one of its arguments (ie, one field)
+      // throws an error, the combined Promise resolves, but there's no
+      // "cancellation" of the Promises that are the other arguments to
+      // `Promise.all`. So the code contributing to those Promises keeps on
+      // chugging away indefinitely.
+      //
+      // Concrete example: let’s say you have
+      //
+      //    { x y { ARBITRARY_SELECTION_SET } }
+      //
+      // where x has a non-null return type, and x and y both have resolvers
+      // that return Promises. And let’s say that x returns a Promise that
+      // rejects (or resolves to null). What this means is that we’re going to
+      // eventually end up with `data: null` (nothing under y will actually
+      // matter), but graphql-js execution will continue running whatever is
+      // under ARBITRARY_SELECTION_SET without any sort of short circuiting. In
+      // fact, the Promise returned from execute itself can happily resolve
+      // while execution is still chugging away on an arbitrary amount of fields
+      // under that ARBITRARY_SELECTION_SET. There’s no way to detect from the
+      // outside "all the execution related to this operation is done", nor to
+      // "short-circuit" execution so that it stops going.
+      //
+      // So, um. We will record any field whose execution we manage to observe
+      // before we "stop" the TraceTreeBuilder (whether it is one that actually
+      // ends up in the response or whether it gets thrown away due to null
+      // bubbling), but if we get any more fields afterwards, we just ignore
+      // them rather than throwing a confusing error.
+      //
+      // (That said, the error we used to throw here generally was hidden
+      // anyway, for the same reason: it comes from a branch of execution that
+      // ends up not being included in the response. But
+      // https://github.com/graphql/graphql-js/pull/3529 means that this
+      // sometimes crashed execution anyway. Our error never caught any actual
+      // problematic cases, so keeping it around doesn't really help.)
+      return () => {};
     }
@@ -91,0 +133,0 @@

No alert changes

Improved metrics

Total package byte prevSize

1825822

increased by0.14%

Lines of code

31906

increased by0.13%

No dependency changes