* Ensure formatError callback is set for subscriptions

* Revert rename of variable

* Fix lint issue

* Update CHANGELOG.md

…ore`.

The actual dependency usage was removed with the move to
`apollo-server-types`, but the reference in `package.json` was inadvertently
left.

This adds additional packages to the release process that are closely
coupled with Apollo Server itself.  It's an alternative to removing the
`--exact` flag from the `lerna publish` step.

I'm taking this route after analyzing the problem exhibited within #3116,
which demonstrates unnecessarily duplicated packages within a particular
installation.

My gut reaction was to remove the `--exact` flag, but seeing as we've
recently seen the Apollo Server 3.x light of having far, far less packages,
I'm going to temporarily turn up the amount of over-publishing packages we
do rather than getting rid of the `--exact` flag just because I don't know
how to guarantee that we're being careful with the versioning on non
`apollo-server-{integration}` packages (e.g. `apollo-tracing`,
`apollo-engine-reporting`, `apollo-cache-control`, etc.), even though I
_believe_ we are cautious and generally doing it correctly.

Ultimately, we've gone this far in the direction of over-publishing out of
an abundance of caution, that I think we will keep doing it until we sunset
this package pattern.

Some additional context: The `--exact` flag for Lerna avoids the use any
range specifiers in the versions used in the published packages'
`package.json` files.  (During development the versions are `file:`
references, and Lerna changes them _just_ before publishing.)

cc @trevor-scheer

* docs: Add pointer to `debugPrintReports` for aer

This allows users to validate why metrics may not be working if they encounter errors.

* Apply suggestions from code review

Thanks Jesse!

Co-Authored-By: Jesse Rosenberger <git@jro.cc>

* Feedback on https://github.com/apollographql/apollo-server/pull/3092\#discussion_r316842126.

* Feedback for #3092 (comment).

Example code on the rootValue field was incorrect

Co-Authored-By: Stephen Barlow <stephen@apollographql.com>
Co-Authored-By: James Baxley <james@apollographql.com>

- The behavior of maxAttempts previously failed to match its documentation or
  the literal reading of its name. Previously, setting maxAttempts=1 would
  actually result in one retry after the initial attempt. This change fixes
  the behavior to match the docs and the name.

- We intend the bodies of Engine report endpoint errors to be useful in error
  logs, even 5xx errors. This change returns to including them in the reported
  error.

PR #1274 (merged before the initial release of apollo-engine-reporting)
regressed both of these issues.

chore(deps): update dependency gatsby-theme-apollo-docs to v1.4.1

Update theme to v2

Previously, the gateway depended on downstream services to report any
errors with graphql execution. In the case of invalid variables, it's
not necessary to make any fetches or even build a query plan since
we can perform that validation when the request is first received.

Validating at the gateway also guarantees that we surface invalid queries to users,
independent of how the downstream services are implemented and what
kind of validation _they_ perform on incoming requests.

Move the service sdl cache from a global variable into the ApolloGateway class

This commit implements value types as a core part of composition
and query planning. With this work, we now:

* build another metadata map for tracking value types
* attach value type metadata to schema type nodes
* attach value type metadata to fields on value types
* make query planning decisions based on value type metadata

With value types, it doesn't make sense for a single service to own
the fields on said value type. Update the types and implementation to reflect
this.

)

Via an upstream PR provided by @spencersteers, this fixes a regression in
GraphQL Playground which prevented the resizing of the schema panel.  This
regression seems to have been introduced by
graphql/graphql-playground#1001, which removed the
relevant binding.

See referenced issues for additional details into the change.

Ref: apollographql/graphql-playground#19
Fixes: #2529

…ngelogs

 - apollo-cache-control@0.8.2
 - apollo-datasource-rest@0.6.2
 - apollo-datasource@0.6.2
 - apollo-engine-reporting@1.4.4
 - @apollo/federation@0.9.1
 - @apollo/gateway@0.10.1
 - apollo-server-azure-functions@2.9.1
 - apollo-server-cache-memcached@0.6.2
 - apollo-server-cache-redis@1.1.2
 - apollo-server-cloud-functions@2.9.1
 - apollo-server-cloudflare@2.9.1
 - apollo-server-core@2.9.1
 - apollo-server-env@2.4.2
 - apollo-server-errors@2.3.2
 - apollo-server-express@2.9.1
 - apollo-server-fastify@2.9.1
 - apollo-server-hapi@2.9.1
 - apollo-server-integration-testsuite@2.9.1
 - apollo-server-koa@2.9.1
 - apollo-server-lambda@2.9.1
 - apollo-server-micro@2.9.1
 - apollo-server-plugin-base@0.6.2
 - apollo-server-plugin-response-cache@0.3.2
 - apollo-server-testing@2.9.1
 - apollo-server-types@0.2.2
 - apollo-server@2.9.1
 - apollo-tracing@0.8.2
 - graphql-extensions@0.10.1

 - @apollo/federation@0.9.2
 - @apollo/gateway@0.10.2

The TypeScript compiler is inferring the return type of this method
accurately, but emitting `import("express-serve-static-core")` directly into
the `apollo-server-express` type definitions.

Looking at the `package-lock.json` for the Apollo Server repository, I have
a working theory that there are multple `@types/express`'s within this project
and that, when resolving the imports in the delcarations, a copy of
`express-serve-static-core` is not quite in the right resolution path —
potentially due to some package hoisting and module resolution.

To be honest, it's just a theory and I only spent about 3 or 4 minutes
looking at this, but I hope that this will address #3222 (intentionally not
using the keyword "Fixes" here because we'll wait for validation!)

* Update koa-bodyparser to ^4.2.1

* Update package-lock.json for updates in #3229.

* Add CHANGELOG.md for #3229.

This follows-up on f710fe4, to see what
happens when we allow wider ranges of versions in depended-upon packages by
utilizing the caret semantic-versioning operator (i.e. `^`).

While I wasn't convinced this was fail-safe, I still think that the changes
in f710fe4 add some value when _also_
applying this change.

In particular, in my current workflow, I'm publishing a new version of
Apollo Server using the `release:server` npm script, and it wants to also
publish new versions of `@apollo/gateway` and `@apollo/federation` merely
because they are depending on `apollo-server-core` and currently specify
their dependency without the caret semver operator.

Note: We'll need to wait until the publish after this to see what the
effects are (since the first publish will introduce the caret operator), but
let's see how this goes! 🧪

cc @trevor-scheer

 - apollo-cache-control@0.8.3
 - apollo-datasource-rest@0.6.3
 - apollo-datasource@0.6.3
 - apollo-engine-reporting@1.4.5
 - @apollo/federation@0.9.3
 - @apollo/gateway@0.10.3
 - apollo-server-azure-functions@2.9.2
 - apollo-server-cache-memcached@0.6.3
 - apollo-server-cache-redis@1.1.3
 - apollo-server-cloud-functions@2.9.2
 - apollo-server-cloudflare@2.9.2
 - apollo-server-core@2.9.2
 - apollo-server-env@2.4.3
 - apollo-server-errors@2.3.3
 - apollo-server-express@2.9.2
 - apollo-server-fastify@2.9.2
 - apollo-server-hapi@2.9.2
 - apollo-server-integration-testsuite@2.9.2
 - apollo-server-koa@2.9.2
 - apollo-server-lambda@2.9.2
 - apollo-server-micro@2.9.2
 - apollo-server-plugin-base@0.6.3
 - apollo-server-plugin-response-cache@0.3.3
 - apollo-server-testing@2.9.2
 - apollo-server-types@0.2.3
 - apollo-server@2.9.2
 - apollo-tracing@0.8.3
 - graphql-extensions@0.10.2