Release 2.7.0 #2937
Merged
Release 2.7.0 #2937
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
abernix
assigned glasser, jbaxleyiii, JacksonKearl, JakeDawkins, trevor-scheer and helenwh
…2932) This reimplements `engine.maskErrorDetails` in terms of `engine.rewriteError`, simplifying the code path around it. It also allows rewriteError implementors slightly more control over the error they produce. Two behavior changes: - If the error returned from the `engine.rewriteError` hook has an `extensions` property, that property will be used instead of the original error's extensions. We now document that changes to most other `GraphQLError` fields by `engine.rewriteError` are ignored. - The `engine.maskErrorDetails` option, deprecated by `engine.rewriteError` in v2.5.0, now behaves a bit more like the new option: while all error messages will be redacted, they will still show up on the appropriate nodes in a trace.
- [email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
|
…`. (#2931) * - changed name of the new option (from enforcePrivateVariables to maskVariableValues), but this is still TBD - use the same helper for both the deprecated privateVariable option and the new option, since the logic is (basically) the same - added helper (and tests) to enforce that originalVariables.keys == modifiedVariables.keys - updated documentation * Changed new option to sendVariableValues instead of maskVariableValues, and the subsequent tests/docs * adding new reporting option sendHeaders, fixing some names * addressing comments, name/argument changes, updating docs, adding and fixing test cases * adding another parameter for specifying safelisted variable names * more doc fixes, adding some checks for invalid inputs * changed suboption name, updating docs with more info on breaking change * Apply suggestions from code review: doc formatting, fixes (equality comparisons, constant declarations), more test cases Co-Authored-By: Jesse Rosenberger <[email protected]> * catching circular reference errors, adding test * Update CHANGELOG.md * Use only the Node.js JSON cycles error. Node.js only raises this particular error when cycles are detected. While I first thought it was more defensive to catch the exact error we anticipated, I'm slightly reconsidering whether this is defensive enough and if we should, in fact, change this back to catching any error, particularly since this runs async and might go undetected or cause a whole string of a user's errors to not pass any variables. Thoughts, @glasser? * Rescind on my suggestion to precisely match the error. I thought it made sense to catch only cycles, but I've changed my mind. I think there could be just arbitrary errors in a `toString` or `toJSON` implementation which we'd still want to guard, particularly because these errors are shipped async. Ref: 4b2f9d3 Ref: #2931 (comment)
|
This adds `getMiddleware` for Express, Koa and Hapi integrations, which are the most pressing locations to reveal the previously-internal, composed middleware which is currently applied via `applyMiddleware`.
- [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
4 tasks
- [email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
It wasn't added to hapi!
It's easier to read a query plan if four steps that'll go in sequence are written Sequence(a, b, c, d) rather than Sequence(a, Sequence(b, Sequence(c, d))).
- @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
* Update GraphQL Playground to fix tab colors when `theme: "light"`. Fixes #2979 * Add CHANGELOG.md
To accommodate the change in graphql/graphql-playground#1051. - `@apollographql/graphql-playground-html`: 1.6.24 - `@apollographql/graphql-playground-react`: 1.7.29 Ref: graphql/graphql-playground#1051 Fixes: #2117
- [email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
These get annoyingly out of synch since we publish some separately, but I think for my 🧠-sake, I'd like to keep them aligned. Maybe I'm being pedantic.
- [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
This was referenced Jul 5, 2019
This moves TypeScript types which are shared by many aspects of Apollo Server into their own, new, `apollo-server-types` package which can be depended on directly by the various parts of Apollo Server (and other Apollo tools) with minimal additional dependency weight. This helps avoid, for example, bringing in the heavier weight of `apollo-server-core` merely to provide some type dependencies. Furthermore, this aims to remove one of the obvious sources of cycles in our dependency graph, which occurs when `apollo-engine-reporting` depends on `apollo-server-core` (for types!), which itself depends on `apollo-engine-reporting`. While these cycles are (roughly) fine at runtime because they're type _merely_ type dependencies, is still made abundantly obvious (read: noisy) during Lerna publishing. As part of this project, I've also moved a couple types from `apollo-server-env` — `PromiseOrValue` and `WithRequired` — into this new `apollo-server-types` package, since they seemed less like ECMAScript compatibility needs (i.e. polyfills; which is primarily what that package aims to provide). Providing these shared types from a package which has import side-effects just seemed like it _could be_ considered bad form and it seemed more appropriate to put them in a "types" package (now that we have it). I've left them in `apollo-server-env` for compatibility reasons, and I suspect `apollo-server-env` will be deprecated soon and replaced with `apollo-env`. Lastly, I've also continued to re-export these types from `packages/apollo-server-core/src/requestPipelineAPI.ts` as a matter of backwards compatibility, but after this change that single file is no longer its own TypeScript project, which was originally done to avoid cycles on `apollo-server-plugin-base`.
- [email protected] - [email protected] - [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
* [BE-308] Federated metrics support
Augments apollo-engine-reporting and @apollo/gateway to provide federated
metrics to Engine from the gateway.
Extend trace reports to contain a QueryPlan tree when traces are received from
a gateway, mimicking the query plan that the gateway makes internally.
FetchNodes on the tree correspond to GraphQL operations executed against
federated services; each FetchNode contains its own tree of Trace.Nodes.
- apollo-engine-reporting
- Factor out core tree building logic to EngineReportingTreeBuilder class
- New EngineFederatedTracingExtension adds a base64-encoded protobuf of a
Trace (with just the node tree and top level timestamps) to an extension
on federated service responses (if requested to do so via an HTTP header
from gateway).
- Implement new originalFieldName trace field (similar goal to #2401, BE-158).
- If @apollo/gateway built us a query plan trace, add it to the trace
- @apollo/gateway
- Builds up a protobuf representation of the query plan, including sub-traces
from federated services on FetchNodes
- apollo-engine-reporting-protobuf
- Copy reports.proto from internal repo
- Set editorconfig settings to match internal repo
- Always use normal numbers, not long.js objects
- apollo-server-core
- Thread some data through between reporting and gateway modules.
- apollo-server-integration-testsuite
- Clean up some ts warnings
TODO record __resolveReference as multiple nodes?
TODO is it actually OK to include the operation text in fetch trace nodes?
TODO more tests, especially of error cases
TODO internal docs (eg FIXME comment in reports.proto)
TODO external docs
* Update protobuf to match cloud repo
* No longer set nonexistent operation field
* Update proto to fix typo
* Convert trace failure into metric
Previously, the logic within executing a query plan would throw an error
and fail the entire operation if it could not parse a trace. Instead, it
adds the information that it failed to parse the trace into the overall
fetch node itself. This commit also adds some comments.
* add snapshot-serializer test
* Add to comment justifying console.warn
* update snapshot
* prettier
* Fixup some imports
Build still breaking :(
* Rely on serviceName instead of error code
We used to rely on the error code matching "DOWNSTREAM_SERVICE_ERROR" in
order to determine that an error was from an underlying service rather
than from the gateway itself. In the past few weeks, error handling in
the gateway has been modified to allow for overriding this error code
with whatever code has come from the gateway, but we are guaranteed to
always have a serviceName if the error comes from a downstream service.
Note, however, that this means if users pass "serviceName" in an error
extension, it will NOT be reported for metrics, even if it occurred at
the Gateway level. We may want to find something less flimsy than this.
* lint fix
* Remove invalid null arguments
* Take suggested log changes
* Publish
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- @apollo/[email protected]
- @apollo/[email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
* empty commit
* Publish
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
* anotha one
* Publish
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
- [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected]
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.7.0 (i.e.release-2.7.0). 🙌As with previous release PRs, the intention of this PR 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. It also gives clarity into exactly what is staged for a release and allows the release to live in in analphaperiod for as long (or as short) as necessary.PRs for new features can be targeted toward this branch when opening the PR (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!
To publish new versions from this branch, run the following:
1. Log in with
apollo-bot2. Publish using the
apollo-botuser credentials.