🐛 Fixes
Fix router coprocessor deferred response buffering and change JSON body type from Object to String (Issue #3015)
The current implementation of the RouterResponse processing for coprocessors forces buffering of response data before passing the data to a coprocessor. This is a bug, because deferred responses should be processed progressively with a stream of calls to the coprocessor as each chunk of data becomes available.
Furthermore, the data type was assumed to be valid JSON for both RouterRequest and RouterResponse coprocessor processing. This is also a bug, because data at this stage of processing was never necessarily valid JSON. This is a particular issue when dealing with deferred (when using @defer) RouterResponses.
This change fixes both of these bugs by modifying the router so that coprocessors are invoked with a body payload which is a JSON String, not a JSON Object. Furthermore, the router now processes each chunk of response data separately so that a coprocessor will receive multiple calls (once for each chunk) for a deferred response.
For more details about how this works see the coprocessor documentation.
Experimental: Query plan cache keys now include a hash of the query and operation name (Issue #2998)
Note
This feature is still experimental and not recommended under normal use nor is it validated that caching query plans in a distributed fashion will result in improved performance.
The experimental feature for caching query plans in a distributed store (e.g., Redis) will now create a SHA-256 hash of the query and operation name and include that hash in the cache key, rather than using the operation document as it was previously.
Federation v2.4.6 (Issue #3133)
This release bumps the Router's Federation support from v2.4.5 to v2.4.6, which brings in notable query planner fixes from v2.4.6. Of note from those releases, this brings query planner fixes that (per that dependency's changelog):
-
Fix assertion error in some overlapping fragment cases. In some cases, when fragments overlaps on some sub-selections (apollographql/federation#2594) and some interface field implementation relied on sub-typing, an assertion error could be raised with a message of the form
Cannot add selection of field X to selection set of parent type Yand this fixes this problem. -
Fix possible fragment-related assertion error during query planning. This prevents a rare case where an assertion with a (apollographql/federation#2596) message of the form
Cannot add fragment of condition X (runtimes: ...) to parent type Y (runtimes: ...)could fail during query planning.
In addition, the packaging includes dependency updates for bytes, regex, once_cell, tokio, and uuid.
Error redaction for subgraphs now respects disabling it
This follows-up on the new ability to selectively disable Studio-bound error redaction which was released in #3011 by fixing a bug which was preventing users from disabling that behavior on subgraphs. Redaction continues to be on by default and both the default behavior and the explicit redact: true option were behaving correctly.
With this fix, the tracing.apollo.errors.subgraph.all.redact option set to false will now transmit the un-redacted error message to Studio.
Evaluate multiple keys matching a JWT criteria (Issue #3017)
In some cases, multiple keys could match what a JWT asks for (both the algorithm, alg, and optional key identifier, kid). Previously, we scored each possible match and only took the one with the highest score. But even then, we could have multiple keys with the same score (e.g., colliding kid between multiple JWKS in tests).
The improved behavior will:
- Return a list of those matching
keyinstead of the one with the highest score. - Try them one by one until the JWT is validated, or return an error.
- If some keys were found with the highest possible score (matching
alg, withkidpresent and matching, too), then we only test those keys.
🛠 Maintenance
chore(deps): xtask/ dependency updates (PR #3149)
This is effectively running cargo update in the xtask/ directory (our directory of tooling; not runtime components) to bring things more up to date.
This changeset takes extra care to update chrono's features to remove the time dependency which is impacted by CVE-2020-26235, resolving a moderate severity which was appearing in scans. Again, this is not a runtime dependency and there was no actual/known impact to any users.
Improve testability of the state_machine in integration tests
We have introduced a TestRouterHttpServer for writing more fine-grained integration tests in the Router core for the behaviors of the state machine.
By @o0Ignition0o in #3099