Allow specifying context arguments with executeOperation (#4166)

Add optional argument to `ApolloServer.executeOperation` allowing the caller to manually specify an argument to the `config` function analogous to that provided by integration packages.

It is the caller's responsibility to figure out what should go in that argument and keep it up to date as they upgrade Apollo Server.

Fixes #2886.

Co-authored-by: David Glasser <[email protected]>

CHANGELOG.md

@@ -12,6 +12,7 @@ The version headers in this history reflect the versions of Apollo Server itself
 > The changes noted within this `vNEXT` section have not been released yet.  New PRs and commits which introduce changes should include an entry in this `vNEXT` section as part of their development.  With few exceptions, the format of the entry should follow convention (i.e., prefix with package name, use markdown `backtick formatting` for package names and code, suffix with a link to the change-set à la `[PR #YYY](https://link/pull/YYY)`, etc.).  When a release is being prepared, a new header will be (manually) created below and the appropriate changes within that release will be moved into the new section.
 
 - Improve startup error handling by ensuring that your server has loaded its schema and executed its `serverWillStart` handlers successfully before starting an HTTP server. If you're using the `apollo-server` package, no code changes are necessary. If you're using an integration such as `apollo-server-express` that is not a "serverless framework", you can insert [`await server.start()`](https://www.apollographql.com/docs/apollo-server/api/apollo-server/#start) between `server = new ApolloServer()` and `server.applyMiddleware`. (If you don't call `server.start()` yourself, your server will still work, but the previous behavior of starting a web server that may fail to load its schema still applies.) The serverless framework integrations (Lambda, Azure Functions, and Cloud Functions) do not support this functionality. While the protected method `willStart` still exists for backwards compatibility, you should replace calls to it with `start` or the new protected method `ensureStarting`. [PR #4981](https://github.com/apollographql/apollo-server/pull/4981)
+- `apollo-server-core`: Add optional argument to `ApolloServer.executeOperation` allowing the caller to manually specify an argument to the `config` function analogous to that provided by integration packages. [PR #4166](https://github.com/apollographql/apollo-server/pull/4166) [Issue #2886](https://github.com/apollographql/apollo-server/issues/2886)
 
 ## v2.21.2
 

packages/apollo-server-core/src/ApolloServer.ts

@@ -1256,8 +1256,22 @@ export class ApolloServerBase {
     };
   }
 
-  public async executeOperation(request: GraphQLRequest) {
-    const options = await this.graphQLServerOptions();
+  /**
+   * This method is primarily meant for testing: it allows you to execute a
+   * GraphQL operation via the request pipeline without going through without
+   * going through the HTTP layer. Note that this means that any handling you do
+   * in your server at the HTTP level will not affect this call!
+   *
+   * If you pass a second argument to this method and your ApolloServer's
+   * `context` is a function, that argument will be passed directly to your
+   * `context` function. It is your responsibility to make it as close as needed
+   * by your `context` function to the integration-specific argument that your
+   * integration passes to `context` (eg, for `apollo-server-express`, the
+   * `{req: express.Request, res: express.Response }` object) and to keep it
+   * updated as you upgrade Apollo Server.
+   */
+  public async executeOperation(request: GraphQLRequest, integrationContextArgument?: Record<string, any>) {
+    const options = await this.graphQLServerOptions(integrationContextArgument);
 
     if (typeof options.context === 'function') {
       options.context = (options.context as () => never)();