Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: v1.60.0 #6647

Draft
wants to merge 101 commits into
base: main
Choose a base branch
from
Draft

release: v1.60.0 #6647

wants to merge 101 commits into from

Conversation

abernix
Copy link
Member

@abernix abernix commented Jan 24, 2025

Note
This particular PR must be true-merged to main.

  • This PR is only ready to review when it is marked as "Ready for Review". It represents the merge to the main branch of an upcoming release (version number in the title).
  • It will act as a staging branch until we are ready to finalize the release.
  • We may cut any number of alpha and release candidate (RC) versions off this branch prior to formalizing it.
  • This PR is primarily a merge commit, so reviewing every individual commit shown below is not necessary since those have been reviewed in their own PR. However, things important to review on this PR once it's marked "Ready for Review":
    • Does this PR target the right branch? (usually, main)
    • Are the appropriate version bumps and release note edits in the end of the commit list (or within the last few commits). In other words, "Did the 'release prep' PR actually land on this branch?"
    • If those things look good, this PR is good to merge!

bryn and others added 30 commits October 3, 2024 20:10
This mode will change the behaviour of the router for tracing in the following ways:

* Spans are never dropped, instead they are converted to RecordOnly.
* Spans that are sent to otlp and datadog exporters will always look like they have been sampled.
* The `sampling.priority` attribute is populated on spans.
* `psr` is populated in trace state.
* `m` is populated in trace state.
We made some weird configuration previously to force particular behaviour which when looked at subsequently didn't make any sense.

In particular the otlp tests should have had otlp propagation with the datadog propagator also enabled.

Also added a chack for the subgraph service to ensure it is correctly sampled.
nmoutschen and others added 24 commits January 16, 2025 12:10
Co-authored-by: Maria Elisabeth Schreiber <[email protected]>
Co-authored-by: Maria Elisabeth Schreiber <[email protected]>
Co-authored-by: Bryn Cooke <[email protected]>
Signed-off-by: Benjamin <[email protected]>
Co-authored-by: Jesse Rosenberger <[email protected]>
…sh (backport #6622) (#6633)

Co-authored-by: Ivan Goncharov <[email protected]>
Co-authored-by: Renée Kooi <[email protected]>
@svc-apollo-docs
Copy link
Collaborator

svc-apollo-docs commented Jan 24, 2025

⚠️ Docs preview not attached to branch

The preview was not built because the PR's base branch main is not in the list of sources.

An Apollo team member can comment one of the following commands to dictate which branch to attach the preview to:

  • !docs set-base-branch dev
  • !docs set-base-branch 1.x

Build ID: 750906b595fbd89fccc75bda

@router-perf
Copy link

router-perf bot commented Jan 24, 2025

CI performance tests

  • connectors-const - Connectors stress test that runs with a constant number of users
  • const - Basic stress test that runs with a constant number of users
  • demand-control-instrumented - A copy of the step test, but with demand control monitoring and metrics enabled
  • demand-control-uninstrumented - A copy of the step test, but with demand control monitoring enabled
  • enhanced-signature - Enhanced signature enabled
  • events - Stress test for events with a lot of users and deduplication ENABLED
  • events_big_cap_high_rate - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity
  • events_big_cap_high_rate_callback - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity using callback mode
  • events_callback - Stress test for events with a lot of users and deduplication ENABLED in callback mode
  • events_without_dedup - Stress test for events with a lot of users and deduplication DISABLED
  • events_without_dedup_callback - Stress test for events with a lot of users and deduplication DISABLED using callback mode
  • extended-reference-mode - Extended reference mode enabled
  • large-request - Stress test with a 1 MB request payload
  • no-tracing - Basic stress test, no tracing
  • reload - Reload test over a long period of time at a constant rate of users
  • step-jemalloc-tuning - Clone of the basic stress test for jemalloc tuning
  • step-local-metrics - Field stats that are generated from the router rather than FTV1
  • step-with-prometheus - A copy of the step test with the Prometheus metrics exporter enabled
  • step - Basic stress test that steps up the number of users over time
  • xlarge-request - Stress test with 10 MB request payload
  • xxlarge-request - Stress test with 100 MB request payload

Comment on lines +1 to +3
### Remove experimental_retry ([PR #6338](https://github.com/apollographql/router/pull/6338))

Remove `experimental_retry`. Looking at our analytics it looks like it's not used and it's not working properly. As it was an experimental feature in order to check if we needed this feature or not we decided to remove it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Remove experimental_retry ([PR #6338](https://github.com/apollographql/router/pull/6338))
Remove `experimental_retry`. Looking at our analytics it looks like it's not used and it's not working properly. As it was an experimental feature in order to check if we needed this feature or not we decided to remove it.
### Remove experimental_retry option ([PR #6338](https://github.com/apollographql/router/pull/6338))
The `experimental_retry` option has been removed due to its limited use and functionality during its experimental phase.

@@ -0,0 +1,13 @@
### Improved BatchProcessor observability ([Issue #6558](https://github.com/apollographql/router/issues/6558))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Improved BatchProcessor observability ([Issue #6558](https://github.com/apollographql/router/issues/6558))
### Improve BatchProcessor observability ([Issue #6558](https://github.com/apollographql/router/issues/6558))

@@ -0,0 +1,10 @@
### Truncating Invalid Error Paths ([PR #6359](https://github.com/apollographql/router/pull/6359))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Truncating Invalid Error Paths ([PR #6359](https://github.com/apollographql/router/pull/6359))
### Truncate invalid error paths ([PR #6359](https://github.com/apollographql/router/pull/6359))

According to the [GraphQL Specification](https://spec.graphql.org/draft/#sel-GAPHRPHCAACCpC8-T) an error path must point to a **response field**:
> If an error can be associated to a particular field in the GraphQL result, it must contain an entry with the key path that details the path of the response field which experienced the error.

If a subgraph error includes a path that can't be matched to a response field, the router now truncates the path to the nearest valid field path.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If a subgraph error includes a path that can't be matched to a response field, the router now truncates the path to the nearest valid field path.
The router now truncates the path to the nearest valid field path if a subgraph error includes a path that can't be matched to a response field,

@@ -0,0 +1,9 @@
### Demand control lookup optimizations ([PR #6450](https://github.com/apollographql/router/pull/6450))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Demand control lookup optimizations ([PR #6450](https://github.com/apollographql/router/pull/6450))
### Optimize demand control lookup ([PR #6450](https://github.com/apollographql/router/pull/6450))

Comment on lines +3 to +7
Demand Control can reduce router throughput due to the extra processing required for scoring. This change shifts more data to be computed at plugin initialization and consolidates lookup queries.

- Cost directives for arguments are now stored in a map alongside those for field definitions
- All precomputed directives are bundled into a struct for each field, along with that field's extended schema type. This reduces 5 individual lookups to a single lookup.
- Response scoring was looking up each field's definition twice. This is now reduced to a single lookup.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Demand Control can reduce router throughput due to the extra processing required for scoring. This change shifts more data to be computed at plugin initialization and consolidates lookup queries.
- Cost directives for arguments are now stored in a map alongside those for field definitions
- All precomputed directives are bundled into a struct for each field, along with that field's extended schema type. This reduces 5 individual lookups to a single lookup.
- Response scoring was looking up each field's definition twice. This is now reduced to a single lookup.
The performance of demand control in the router has been optimized.
Previously, demand control could reduce router throughput due to its extra processing required for scoring.
This fix improves performance by shifting more data to be computed at plugin initialization and consolidating lookup queries:
- Cost directives for arguments are now stored in a map alongside those for field definitions
- All precomputed directives are bundled into a struct for each field, along with that field's extended schema type. This reduces 5 individual lookups to a single lookup.
- Response scoring was looking up each field's definition twice. This is now reduced to a single lookup.

@@ -0,0 +1,11 @@
### Remove the legacy query planner ([PR #6418](https://github.com/apollographql/router/pull/6418))

The legacy query planner has been removed in this release. In the previous release, Router 1.58, it was already no longer used by default but it was still available through the `experimental_query_planner_mode` configuration key. That key is now removed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The legacy query planner has been removed in this release. In the previous release, Router 1.58, it was already no longer used by default but it was still available through the `experimental_query_planner_mode` configuration key. That key is now removed.
The legacy query planner has been removed in this release. In the previous release, router v1.58, it was no longer used by default but was still available through the `experimental_query_planner_mode` configuration key. That key is now removed.

@lrlna
Copy link
Member

lrlna commented Jan 28, 2025

#6654 should land in 1.60.0 too, ideally

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.