Release 2.6.0 #2669
Merged
Release 2.6.0 #2669
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Disable callbackWaitsForEmptyEventLoop for HTTP OPTIONS request since ApolloServer already disable callbackWaitsForEmptyEventLoop for POST request. (https://github.com/apollographql/apollo-server/blob/1ec2890397ca306350b0e1f33eec7b5f3f951d8d/packages/apollo-server-lambda/src/lambdaApollo.ts#L33) Otherwise is lambda event loop is not empty, subsequence HTTP OPTIONS request will be hang and even timeout without throwing proper error.
fix prettier issue
This makes no actual changes to the function, but it moves this rather large block of code out of the `constructor` for `EngineReportingExtension`.
#2668) chore: Move default client signature generation into its own function.
This was referenced May 15, 2019
Because the graphql-playground-react from prisma move to @apollographql [Commit Here](apollographql/graphql-playground@f93d93d) so the CDN just support 1.7.24 and 1.7.25 like [CND](https://www.jsdelivr.com/package/npm/@apollographql/graphql-playground-react)
The `WithRequired` typing declarations throughout the request pipeline API are meant to provide integrations with type safety for their hook implementations: a contract between plugins and Apollo Server itself. We've added some additional properties to the `requestContext` that the request pipeline API (already) receives but, up until this commit, those properties haven't been explicitly marked as `WithRequired` by the request pipeline. I'd love to say this was my own observation but, full disclosure, while these are not TypeScript compilation errors (in the eyes of `tsc`) this was prompted by some new red-squiggles in my editor which hadn't been present before. Upon investigation, it appears that it's right! This updates the internal request pipeline types to match that of the `apollo-server-plugin-base` package, which is meant to be used by plugin implementers and can be seen here: https://github.com/apollographql/apollo-server/blob/b3cbb42d/packages/apollo-server-plugin-base/src/index.ts As some point, I think we'll probably want to consider re-using those from within the request pipeline, if possible.
* Defer and cache calculation of Engine reporting signature. This moves the Apollo Engine Reporting signature calculation (which the Apollo Cloud uses to aggregate similar operations) to perform asynchronously, after the response has been returned to the client, and also caches the signature for use by additional operations which match the same `queryHash` (which is an exact SHA-256 hex digest of the operation body received from the client). While the signature calculation is relatively quick on small operations, with sustained load and more complex operations, this recurring calculation can be more costly. As a bit of validation to the success of this change, on a very basic performance benchmark, using a schema with 1000 `String` fields (i.e. a `type Query` with `Field_1: String` through `Field_1000: String`) and an incoming operation which selects from all 1000 of those fields (i.e `Field_1`), this showed quite an improvement: ``` ┌───────────────┬───────────────┬───────────────┐ │ │ Before │ After │ ├───────────────┼───────────────┼───────────────┤ │ Percentile, % │ Resp. Time, s │ Resp. Time, s │ ├───────────────┼───────────────┼───────────────┤ │ 0.0 │ 0.076 │ 0.024 │ │ 50.0 │ 0.342 │ 0.14 │ │ 90.0 │ 0.388 │ 0.161 │ │ 95.0 │ 0.41 │ 0.164 │ │ 99.0 │ 0.444 │ 0.17 │ │ 99.9 │ 0.486 │ 0.177 │ │ 100.0 │ 0.487 │ 0.196 │ └───────────────┴───────────────┴───────────────┘ ``` Of course, this is a relatively simple example and still includes actual GraphQL execution, but the win factor is certainly there. Other tests with more dynamic fields and a higher cardinality of unique operations also showed improvement, though extremely high cardinality of complex operations (which have more expensive execution characteristics) certainly made the _win_ factor less pronounced. It's not surprising that this calculation is a bit expensive since it requires a number of normalization steps. Luckily, we can let this all happen after the request is sent to the client and it's highly cacheable. By default, we'll use a relatively small cache which should store a large number of operations, and to avoid introducing configuration surface area right now without much evidence as to the need, we'll simply log a message periodically if we're ejecting operations. * Publish - apollo-cache-control@0.7.0-alpha.0 - apollo-engine-reporting@1.2.0-alpha.0 - apollo-server-azure-functions@2.6.0-alpha.0 - apollo-server-cloud-functions@2.6.0-alpha.0 - apollo-server-cloudflare@2.6.0-alpha.0 - apollo-server-core@2.6.0-alpha.0 - apollo-server-express@2.6.0-alpha.0 - apollo-server-fastify@2.6.0-alpha.0 - apollo-server-hapi@2.6.0-alpha.0 - apollo-server-integration-testsuite@2.6.0-alpha.0 - apollo-server-koa@2.6.0-alpha.0 - apollo-server-lambda@2.6.0-alpha.0 - apollo-server-micro@2.6.0-alpha.0 - apollo-server-plugin-base@0.5.0-alpha.0 - apollo-server-plugin-response-cache@0.2.0-alpha.0 - apollo-server-testing@2.6.0-alpha.0 - apollo-server@2.6.0-alpha.0 - apollo-tracing@0.7.0-alpha.0 - graphql-extensions@0.7.0-alpha.0 * Use `operationName` as part of cache key for Engine reporting signature. Per astute feedback from @martijnwalraven!
- apollo-cache-control@0.7.0-alpha.1 - apollo-engine-reporting@1.2.0-alpha.1 - apollo-server-azure-functions@2.6.0-alpha.1 - apollo-server-cloud-functions@2.6.0-alpha.1 - apollo-server-cloudflare@2.6.0-alpha.1 - apollo-server-core@2.6.0-alpha.1 - apollo-server-express@2.6.0-alpha.1 - apollo-server-fastify@2.6.0-alpha.1 - apollo-server-hapi@2.6.0-alpha.1 - apollo-server-integration-testsuite@2.6.0-alpha.1 - apollo-server-koa@2.6.0-alpha.1 - apollo-server-lambda@2.6.0-alpha.1 - apollo-server-micro@2.6.0-alpha.1 - apollo-server-plugin-base@0.5.0-alpha.1 - apollo-server-plugin-response-cache@0.2.0-alpha.1 - apollo-server-testing@2.6.0-alpha.1 - apollo-server@2.6.0-alpha.1 - apollo-tracing@0.7.0-alpha.1 - graphql-extensions@0.7.0-alpha.1
This re-implements the triggering of `didEncounterErrors` during `willResolveOperation` errors which occur in the request pipeline, but in a more common spot and where it probably should have been getting called already anyway.
This aims to accomplish one of the bits which was included within #2659 via a technique that scopes the errors more precisely. While I do think we should be passing all errors, the fix in #2659 was specifically aimed at a particular error-case which surfaced and we should consider a more refined approach to capturing those errors in the right places in future API iterations.
This is another take on #2659 which has been otherwise excluded from the 2.6.0 release. The work in #2659 was meant to ensure that the `document` and `operationName` were set at the appropriate locations within the lifecycle events for the `graphql-extensions` module, specifically when an error had been thrown within `didResolveOperation` of the new request pipeline. While the solution in #2659 certainly works, it introduced a new life-cycle method for details which we could also calculate without adding to the API surface area by using information which was already exposed. Even though `graphql-extensions` is no longer really being supported, avoiding growth on the API surface area of `graphql-extensions` is still important for any API! Ref: #2659
…eOperation-errors-to-willSendResponse engine-reporting: Handle errors within `didResolveOperation` life-cycle hook.
…s. (#2711) engine-reporting: Capture `operationName` and `document` within errors.
- apollo-engine-reporting@1.2.0-alpha.2 - apollo-server-azure-functions@2.6.0-alpha.2 - apollo-server-cloud-functions@2.6.0-alpha.2 - apollo-server-cloudflare@2.6.0-alpha.2 - apollo-server-core@2.6.0-alpha.2 - apollo-server-express@2.6.0-alpha.2 - apollo-server-fastify@2.6.0-alpha.2 - apollo-server-hapi@2.6.0-alpha.2 - apollo-server-integration-testsuite@2.6.0-alpha.2 - apollo-server-koa@2.6.0-alpha.2 - apollo-server-lambda@2.6.0-alpha.2 - apollo-server-micro@2.6.0-alpha.2 - apollo-server-plugin-base@0.5.0-alpha.2 - apollo-server-testing@2.6.0-alpha.2 - apollo-server@2.6.0-alpha.2 - graphql-extensions@0.7.0-alpha.2
- apollo-engine-reporting@1.2.0-alpha.3 - apollo-server-azure-functions@2.6.0-alpha.3 - apollo-server-cloud-functions@2.6.0-alpha.3 - apollo-server-cloudflare@2.6.0-alpha.3 - apollo-server-core@2.6.0-alpha.3 - apollo-server-express@2.6.0-alpha.3 - apollo-server-fastify@2.6.0-alpha.3 - apollo-server-hapi@2.6.0-alpha.3 - apollo-server-integration-testsuite@2.6.0-alpha.3 - apollo-server-koa@2.6.0-alpha.3 - apollo-server-lambda@2.6.0-alpha.3 - apollo-server-micro@2.6.0-alpha.3 - apollo-server-plugin-base@0.5.0-alpha.3 - apollo-server-testing@2.6.0-alpha.3 - apollo-server@2.6.0-alpha.3 - graphql-extensions@0.7.0-alpha.3
**Note:** This currently only covers error conditions. Read below for details. This commit aims to provide user-configurable opt-in to mapping GraphQL-specific behavior to HTTP status codes under error conditions, which are not always a 1:1 mapping and often implementation specific. HTTP status codes — traditionally used for a single resource and meant to represent the success or failure of an entire request — are less natural to GraphQL which supports partial successes and failures within the same response. For example, some developers might be leveraging client implementations which rely on HTTP status codes rather than checking the `errors` property in a GraphQL response for an `AuthenticationError`. These client implementations might necessitate a 401 status code. Or as another example, perhaps there's some monitoring infrastructure in place that doesn't understand the idea of partial successes and failures. (Side-note: Apollo Engine aims to consider these partial failures, and we're continuing to improve our error observability. Feedback very much appreciated.) I've provided some more thoughts on this matter in my comment on: #2269 (comment) This implementation falls short of providing the more complete implementation which I aim to provide via a `didEnounterErrors` life-cycle hook on the new request pipeline, but it's a baby-step forward. It was peculiar, for example, that we couldn't already mostly accomplish this through the `willSendResponse` life-cycle hook. Leveraging the `willSendResponse` life-cycle hook has its limitations though. Specifically, it requires that the implementer leverage the already-formatted errors (i.e. those that are destined for the client in the response), rather than the UN-formatted errors which are more ergonomic to server-code (read: internal friendly). Details on the `didEncounterErrors` proposal are roughly discussed in this comment: #1709 (comment) (tl;dr The `didEncounterErrors` hook would receive an `errors` property which is pre-`formatError`.) As I opened this commit message with: It's critical to note that this DOES NOT currently provide the ability to override the HTTP status code for "success" conditions, which will continue to return "200 OK" for the time-being. This requires more digging around in various places to get correct, and I'd like to give it a bit more consideration. Errors seem to be the pressing matter right now. Hopefully the `didEncounterErrors` hook will come together this week.
- apollo-cache-control@0.7.0-alpha.6 - apollo-engine-reporting@1.2.0-alpha.6 - apollo-server-azure-functions@2.6.0-alpha.6 - apollo-server-cache-redis@1.0.0-alpha.6 - apollo-server-cloud-functions@2.6.0-alpha.6 - apollo-server-cloudflare@2.6.0-alpha.6 - apollo-server-core@2.6.0-alpha.6 - apollo-server-express@2.6.0-alpha.6 - apollo-server-fastify@2.6.0-alpha.6 - apollo-server-hapi@2.6.0-alpha.6 - apollo-server-integration-testsuite@2.6.0-alpha.6 - apollo-server-koa@2.6.0-alpha.6 - apollo-server-lambda@2.6.0-alpha.6 - apollo-server-micro@2.6.0-alpha.6 - apollo-server-plugin-base@0.5.0-alpha.6 - apollo-server-plugin-response-cache@0.2.0-alpha.6 - apollo-server-testing@2.6.0-alpha.6 - apollo-server@2.6.0-alpha.6 - graphql-extensions@0.7.0-alpha.6
This accounts for some preliminary tests for things which don't already have tests, but was primarily motivated by the new `didEncounterErrors` life-cycle hooks that I introduced in #2719.
…#2324) * lazy load unused lambda packages in core * Style adjustments plus changes to account for other PRs with similar motives. The work in #2054 was designed in a way that, irregardless of the environment, the `graphql-upload` package would only be loaded if uploads were enabled. Therefore, the guard which checks `process.env.AWS_EXECUTION_ENV` should no longer be necessary. Additionally, we don't need to prefix our type-only variables with underscores, as that's not a style that we've otherwise adopted. * The work in this was mostly also implemented by #2305, #2304 and #2054, but the remaining subscriptions-transport-ws and unnecessary util.promisify imports are still super worth addressing. So, thank you!
- apollo-cache-control@0.7.0-alpha.7 - apollo-datasource-rest@0.4.1-alpha.5 - apollo-datasource@0.4.1-alpha.0 - apollo-engine-reporting@1.2.0-alpha.7 - apollo-server-azure-functions@2.6.0-alpha.7 - apollo-server-cache-memcached@0.4.1-alpha.0 - apollo-server-cache-redis@1.0.0-alpha.7 - apollo-server-cloud-functions@2.6.0-alpha.7 - apollo-server-cloudflare@2.6.0-alpha.7 - apollo-server-core@2.6.0-alpha.7 - apollo-server-env@2.3.1-alpha.0 - apollo-server-express@2.6.0-alpha.7 - apollo-server-fastify@2.6.0-alpha.7 - apollo-server-hapi@2.6.0-alpha.7 - apollo-server-integration-testsuite@2.6.0-alpha.7 - apollo-server-koa@2.6.0-alpha.7 - apollo-server-lambda@2.6.0-alpha.7 - apollo-server-micro@2.6.0-alpha.7 - apollo-server-plugin-base@0.5.0-alpha.7 - apollo-server-plugin-response-cache@0.2.0-alpha.7 - apollo-server-testing@2.6.0-alpha.7 - apollo-server@2.6.0-alpha.7 - apollo-tracing@0.7.0-alpha.2 - graphql-extensions@0.7.0-alpha.7
In the same way as `editor.theme` is cast to `Theme`.
…gs`. It appears that the `hideQueryPlanResponse` is now a required member of the `ISettings` interface within `graphql-playground-html`, thereby mandating that any existing implementer of `ISettings` (via, for example, `MiddlewareOptions` or `RenderPageOptions` respective `settings` properties woudl necessitate that they have that property added. This might be possible if `'queryPlan.hideQueryPlanResponse'` was not a required property, but merely optional? cc @trevor-scheer
As helpfully debugged and identified by @dsanders11 (Thank you!), this was a mistake in my original implementation that incorrectly spread the iterable `Headers` into the `headers` object of the response. While I would have loved to create a regression test for this, there was no place which was currently wired up to support handler specific options (like `cors`), which is sometimes on the top-level constructor to `ApolloServer`, and sometimes on `createHandler` or `applyMiddleware`. I did try to futz with it for a full hour to no avail. I'm already aware of a number of limitations with the current so-called `integration-testsuite`, and I'm putting that on the list of things to address in an upcoming overhaul of that testing infra. That said, I've manually tested this and I think it's working properly. An upcoming release should hopefully confirm that. Ref: https://github.com/apollographql/apollo-server/pull/2674/files#r288053103 Ref: #2718 (comment)
- apollo-engine-reporting@1.2.0-alpha.8 - apollo-server-azure-functions@2.6.0-alpha.8 - apollo-server-cloud-functions@2.6.0-alpha.8 - apollo-server-cloudflare@2.6.0-alpha.8 - apollo-server-core@2.6.0-alpha.8 - apollo-server-express@2.6.0-alpha.8 - apollo-server-fastify@2.6.0-alpha.8 - apollo-server-hapi@2.6.0-alpha.8 - apollo-server-integration-testsuite@2.6.0-alpha.8 - apollo-server-koa@2.6.0-alpha.8 - apollo-server-lambda@2.6.0-alpha.8 - apollo-server-micro@2.6.0-alpha.8 - apollo-server-plugin-base@0.5.0-alpha.8 - apollo-server-testing@2.6.0-alpha.8 - apollo-server@2.6.0-alpha.8 - graphql-extensions@0.7.0-alpha.8
- apollo-datasource-rest@0.4.1-alpha.6 - apollo-engine-reporting@1.2.0-alpha.9 - @apollo/federation@0.5.1-alpha.0 - @apollo/gateway@0.5.1-alpha.0 - apollo-server-azure-functions@2.6.0-alpha.9 - apollo-server-cloud-functions@2.6.0-alpha.9 - apollo-server-cloudflare@2.6.0-alpha.9 - apollo-server-core@2.6.0-alpha.9 - apollo-server-express@2.6.0-alpha.9 - apollo-server-fastify@2.6.0-alpha.9 - apollo-server-hapi@2.6.0-alpha.9 - apollo-server-integration-testsuite@2.6.0-alpha.9 - apollo-server-koa@2.6.0-alpha.9 - apollo-server-lambda@2.6.0-alpha.9 - apollo-server-micro@2.6.0-alpha.9 - apollo-server-plugin-base@0.5.0-alpha.9 - apollo-server-testing@2.6.0-alpha.9 - apollo-server@2.6.0-alpha.9 - graphql-extensions@0.7.0-alpha.9
- apollo-engine-reporting@1.2.0-rc.0 - @apollo/gateway@0.5.1-rc.0 - apollo-server-azure-functions@2.6.0-rc.0 - apollo-server-cloud-functions@2.6.0-rc.0 - apollo-server-cloudflare@2.6.0-rc.0 - apollo-server-core@2.6.0-rc.0 - apollo-server-express@2.6.0-rc.0 - apollo-server-fastify@2.6.0-rc.0 - apollo-server-hapi@2.6.0-rc.0 - apollo-server-integration-testsuite@2.6.0-rc.0 - apollo-server-koa@2.6.0-rc.0 - apollo-server-lambda@2.6.0-rc.0 - apollo-server-micro@2.6.0-rc.0 - apollo-server-plugin-base@0.5.0-rc.0 - apollo-server-testing@2.6.0-rc.0 - apollo-server@2.6.0-rc.0 - graphql-extensions@0.7.0-rc.0
|
I've promoted 2.6.0 to a release candidate and it includes the following packages under the same 2.6.0 umbrella ☂️ : The only changes between now and when this release is finalized will be bug-fixes related to changes in this PR. We've been using it to serve Apollo Engine for the last week without trouble, but please do take the opportunity to try it out! |
- apollo-cache-control@0.7.0 - apollo-datasource-rest@0.5.0 - apollo-datasource@0.5.0 - apollo-engine-reporting@1.2.0 - @apollo/federation@0.6.0 - @apollo/gateway@0.6.0 - apollo-server-azure-functions@2.6.0 - apollo-server-cache-memcached@0.5.0 - apollo-server-cache-redis@1.0.0 - apollo-server-cloud-functions@2.6.0 - apollo-server-cloudflare@2.6.0 - apollo-server-core@2.6.0 - apollo-server-env@2.4.0 - apollo-server-express@2.6.0 - apollo-server-fastify@2.6.0 - apollo-server-hapi@2.6.0 - apollo-server-integration-testsuite@2.6.0 - apollo-server-koa@2.6.0 - apollo-server-lambda@2.6.0 - apollo-server-micro@2.6.0 - apollo-server-plugin-base@0.5.0 - apollo-server-plugin-response-cache@0.2.0 - apollo-server-testing@2.6.0 - apollo-server@2.6.0 - apollo-tracing@0.7.0 - graphql-extensions@0.7.0
|
These have been released and promoted to |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a PR tracking a
release-x.y.zbranch for an upcoming semver minor release of Apollo Server: v2.6.0 (i.e.release-2.6.0).The intention here is to keep the
masterbranch a bit more flexible while landing things which have been decidedly put into a release on this more specific release branch. PRs for new features can be targeted toward this branch (and thus will appear in this PR's history), in addition to being merged into the master branch and providing the ability to backport fixes more easily.Periodically, prior to this release going into the release candidate phase (i.e.
-rc.0), themasterbranch will be merged into it. Once in release candidate,masterwill no longer be merged in and only bug fixes for the current release will be added. Finally, when this version is released, this PR will be merged intomaster.Check the appropriate milestone (to the right) for more details on what we hope to get into this release!