You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+87-3
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,90 @@ All notable changes to Router will be documented in this file.
4
4
5
5
This project adheres to [Semantic Versioning v2.0.0](https://semver.org/spec/v2.0.0.html).
6
6
7
+
# [1.61.1] - 2025-03-26
8
+
9
+
> [!IMPORTANT]
10
+
>
11
+
> If you have enabled [Distributed query plan caching](https://www.apollographql.com/docs/router/configuration/distributed-caching/#distributed-query-plan-caching), this release contains changes which necessarily alter the hashing algorithm used for the cache keys. On account of this, you should anticipate additional cache regeneration cost when updating between these versions while the new hashing algorithm comes into service.
When the router reloads, either via schema change or config change, a new request pipeline is created.
18
+
Existing request pipelines are closed once their requests finish. However, this may not happen if there are ongoing long requests that do not finish, such as Subscriptions.
19
+
20
+
To enable debugging when request pipelines are being kept around, a new gauge metric has been added:
21
+
22
+
- `apollo.router.pipelines` - The number of request pipelines active in the router
23
+
- `schema.id` - The Apollo Studio schema hash associated with the pipeline.
24
+
- `launch.id` - The Apollo Studio launch id associated with the pipeline (optional).
25
+
- `config.hash` - The hash of the configuration
26
+
27
+
By [@BrynCooke](https://github.com/BrynCooke) in https://github.com/apollographql/router/pull/6967
To help users to diagnose when connections are keeping pipelines hanging around, the following metric has been added:
32
+
- `apollo.router.open_connections` - The number of request pipelines active in the router
33
+
- `schema.id` - The Apollo Studio schema hash associated with the pipeline.
34
+
- `launch.id` - The Apollo Studio launch id associated with the pipeline (optional).
35
+
- `config.hash` - The hash of the configuration.
36
+
- `server.address` - The address that the router is listening on.
37
+
- `server.port` - The port that the router is listening on if not a unix socket.
38
+
- `state` - Either `active` or `terminating`.
39
+
40
+
You can use this metric to monitor when connections are open via long running requests or keepalive messages.
41
+
42
+
By [@BrynCooke](https://github.com/BrynCooke) in https://github.com/apollographql/router/pull/7009
43
+
44
+
### Add `batching.maximum_size` configuration option to limit maximum client batch size ([PR #7005](https://github.com/apollographql/router/pull/7005))
45
+
46
+
Add an optional `maximum_size` parameter to the batching configuration.
47
+
48
+
* When specified, the router will reject requests which contain more than `maximum_size` queries in the client batch.
49
+
* When unspecified, the router performs no size checking (the current behavior).
50
+
51
+
If the number of queries provided exceeds the maximum batch size, the entire batch fails with error code 422 (`Unprocessable Content`). For example:
52
+
53
+
```json
54
+
{
55
+
"errors": [
56
+
{
57
+
"message": "Invalid GraphQL request",
58
+
"extensions": {
59
+
"details": "Batch limits exceeded: you provided a batch with 3 entries, but the configured maximum router batch size is 2",
60
+
"code": "BATCH_LIMIT_EXCEEDED"
61
+
}
62
+
}
63
+
]
64
+
}
65
+
```
66
+
67
+
By [@carodewig](https://github.com/carodewig) in https://github.com/apollographql/router/pull/7005
68
+
69
+
## 🐛 Fixes
70
+
71
+
### Use correct default values on omitted OTLP endpoints ([PR #6931](https://github.com/apollographql/router/pull/6931))
72
+
73
+
Previously, when the configuration didn't specify an OTLP endpoint, the Router would always default to `http://localhost:4318`. However, port `4318` is the correct default only for the HTTP protocol, while port `4317` should be used for gRPC.
74
+
75
+
Additionally, all other telemetry defaults in the Router configuration consistently use `127.0.0.1` as the hostname rather than `localhost`.
76
+
77
+
With this change, the Router now uses:
78
+
* `http://127.0.0.1:4317` as the default for gRPC protocol
79
+
* `http://127.0.0.1:4318` as the default for HTTP protocol
80
+
81
+
This ensures protocol-appropriate port defaults and consistent hostname usage across all telemetry configurations.
82
+
83
+
By [@IvanGoncharov](https://github.com/IvanGoncharov) in https://github.com/apollographql/router/pull/6931
84
+
85
+
### Separate entity keys and representation variables in entity cache key ([Issue #6673](https://github.com/apollographql/router/issues/6673))
86
+
87
+
This fix separates the entity keys and representation variable values in the cache key, to avoid issues with `@requires` for example.
88
+
89
+
By [@bnjjj](https://github.com/bnjjj) in https://github.com/apollographql/router/pull/6888
90
+
7
91
# [1.61.0] - 2025-02-25
8
92
9
93
## 🚀 Features
@@ -31,11 +115,11 @@ By [@LongLiveCHIEF](https://github.com/LongLiveCHIEF) in https://github.com/apol
31
115
32
116
## 🐛 Fixes
33
117
34
-
### Query Planning: fix `__typename` selections in sibling typename optimization
118
+
### Query Planning: fix `__typename` selections in sibling typename optimization
35
119
36
-
The query planner uses an optimization technique called "sibling typename", which attaches `__typename` selections to their sibling selections so the planner won't need to plan them separately.
120
+
The query planner uses an optimization technique called "sibling typename", which attaches `__typename` selections to their sibling selections so the planner won't need to plan them separately.
37
121
38
-
Previously, when there were multiple identical selections and one of them has a `__typename` attached, the query planner could pick the one without the attachment, effectively losing a `__typename` selection.
122
+
Previously, when there were multiple identical selections and one of them has a `__typename` attached, the query planner could pick the one without the attachment, effectively losing a `__typename` selection.
39
123
40
124
Now, the query planner favors the one with a `__typename` attached without losing the `__typename` selection.
0 commit comments