Optional timeout layer pub elapsed #9
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
…phql#4921) The schema aware hash does not take the operation name into account, but the operation name is used in the operation signature, so if the same query is used with 2 different operation names, then they would get the same operation signature, which might disrupt the data in studio
Co-authored-by: Edward Huang <edward.huang@apollographql.com>
Still makes Helm sense in the re-write. Co-authored-by: Jeremy Lempereur <jeremy.lempereur@iomentum.com>
Make clear what is fixed and document the warning messages that have gone away.
…pollographql#4945) otherwise the test_updated CI build will fail
CircleCI OSX x86_64 workers are deprecated and will be removed in June. To get ahead of that, we are now building those versions from the M1 workers. This required a change in router-bridge, to start the deno instance of the query planner without snapshots: apollographql/federation-rs@6c23a07 In our tests, this did not really affect the startup time, this change is safe to use. Co-authored-by: o0Ignition0o <jeremy.lempereur@gmail.com>
…#4796) This PR introduces experimental support for generating the stats report key (signature) and referenced fields in native rust code instead of using what is generated by router-bridge as part of query planning. There were a number of gotchas that I found in the JS code that I have faithfully ported across, but at this point I've run enough unit tests and fuzz testing that I'm confident it's generating the same as the JS code. Co-authored-by: o0Ignition0o <jeremy.lempereur@gmail.com> Co-authored-by: Geoffroy Couprie <apollo@geoffroycouprie.com>
…hql#4946) router-bridge was added as a dendency of router-fuzz in a recent PR, but the dependency in apollo-router had been upgraded in the meantime. This switches to specify common dependencies in the workspace, so that version numbers are de-duplicated. Note that `Cargo.lock` is not changed by this PR. <!-- start metadata --> --- **Checklist** Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review. - [ ] Changes are compatible[^1] - [ ] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [ ] Unit Tests - [ ] Integration Tests - [ ] Manual Tests **Exceptions** *Note any exceptions here* **Notes** [^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions.
…bumps and changelog updates into the dev branch.
There are currently 2 different ways to create metrics, with slight incompatibilities. This makes sure that the execution stage coprocessor metrics are generated in the same way as the other stages
…ql#4949) Error messages are now mostly the same as the graphql-js messages from before (where possible). GraphQL syntax errors are reported as `PARSING_ERROR` again instead of as `GRAPHQL_VALIDATION_ERROR`. `SpecError::ParsingError` is replaced by `SpecError::ParseError` which contains structured error information similar to `SpecError::ValidationError`. The other uses of `ParsingError` are replaced by `TransformError`, as most of them are in query transforms/filtering. The error messages for `TransformError` remain the same. There will still be differences in error messages, especially when querying undefined fields etc, because previously those would hit an error case deep inside the router whereas now they will be rejected early on. This is an easily explainable difference with obvious benefits for users, so I think it's acceptable. <!-- start metadata --> --- **Checklist** Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review. - [ ] Changes are compatible[^1] - [ ] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [ ] Unit Tests - [ ] Integration Tests - [ ] Manual Tests **Exceptions** *Note any exceptions here* **Notes** [^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions.
…pollographql#4920) 1. Replace unordered HashSet/HashMap with IndexSet/IndexMap. It makes predictable order of variable names inside error messages 2. Add unit tests 3. For Parallel node simplify result query plan by doing special handling of cases: a. if only one subnode is using files don't change anything b. if all subnodes are using files replace `Parallel` with `Sequence` <!-- start metadata --> --- **Checklist** Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review. - [ ] Changes are compatible[^1] - [ ] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [x] Unit Tests - [ ] Integration Tests - [ ] Manual Tests **Exceptions** *Note any exceptions here* **Notes** [^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions.
Docs for query planner pool (apollographql#4897)
[apollographql#2489](apollographql#2489) introduced automatic aliasing rules to support `@interfaceObject`. These rules now properly apply to lists.
This project is an extension of the existing work to support [client side batching in the router](apollographql#126). The current implementation is experimental and is publicly [documented](https://www.apollographql.com/docs/router/executing-operations/query-batching/). The additional work to enable batching requests to subgraphs is captured in [this issue](apollographql#2002). Currently the concept of a batch is preserved until the end of the RouterRequest processing. At this point we convert each batch request item into a separate SupergraphRequest. These are then planned and executed concurrently within the router and re-assembled into a batch when they complete. It's important to note that, with this implementation, the concept of a batch, from the perspective of an executing router, now disappears and each request is planned and executed separately. This extension will modify the router so that the concept of a batch is preserved, at least outwardly, so that multiple subgraph requests are "batched" (in exactly the same format as a client batch request) for onward transmission to subgraphs. The goal of this work is to provide an optimisation by reducing the number of round-trips to a subgraph from the router. Additionally, the work will address an [unresolved issue](apollographql#4019) from the existing experimental implementation and promote the existing implementation from experimental to fully supported. Fixes apollographql#2002 <!-- start metadata --> --- **Review Guidance** This is a fairly big PR, so I've written these notes to help make the review more approachable. 1. The most important files to review are (in order): - [.changesets/feat_garypen_2002_subgraph_batching.md](https://github.com/apollographql/router/pull/4661/files#diff-6376c91cfdd47332a662c760ac849bb5449a1b6df6891b30b72b43f041bd836f) - [docs/source/executing-operations/query-batching.mdx](https://github.com/apollographql/router/pull/4661/files#diff-617468db3057857f71c387eaa0d1a6161e3c1b8bf9fcb2de6fc6eafedc147277) - [apollo-router/src/services/router/service.rs](https://github.com/apollographql/router/pull/4661/files#diff-544579a213fda1bff6313834d30fe1746a8a28ffd7c0d6dfa1081fa36a487355) - [apollo-router/src/services/supergraph/service.rs](https://github.com/apollographql/router/pull/4661/files#diff-5d72a88a68962a5926fb5bb115ea3efc186904612f74e697d72e3f009669c733) - [apollo-router/src/query_planner/plan.rs](https://github.com/apollographql/router/pull/4661/files#diff-21a82d277d12e8f21b6b71398d62e95303a117130cc4a27510b85ebfceeb8208) - [apollo-router/src/services/subgraph_service.rs](https://github.com/apollographql/router/pull/4661/files#diff-6ef5a208ca8622f30eef88f75c18566e0304d59856b66293dcd6811555e6382e) - [apollo-router/src/batching.rs](https://github.com/apollographql/router/pull/4661/files#diff-3e884074ecad8176341159a2382aa81c49d74b851894b8ade9fa4718c434dec6) First read the documentation. Hopefully that will make clear how this feature works. I've picked these files as being most important (and ordered them for review) because: router service => This is where we spot incoming batches and create context `BatchQuery` items to manage them through the router. We also re-assemble them on the way back and identify any batches which may need to be cancelled. supergraph service => Here we pick up the information about how many fetches we believe each `BatchQuery` will need to make. plan => The new `query_hashes()` does this fetch identification for us. This is the most important function in this feature. subgraph service => Here's is where we intercept the calls to subgraphs and park threads to wait for batch execution to be performed. We do a lot of work here, so this is where most of the intrusive changes are: assembling and dis-assembling batches and managing the co-ordination between a number of parked tasks. batching => This is the implementation of batch co-ordination. Each batch has a task which manages a variety of channels to facilitate communication between the incoming batches, waiting tasks and outgoing (to subgraph) batches. I'm suggesting reading this *after* reading through the service changes because it should mainly just be implementation details and you will be able to follow what is happening without knowing all this detail initially. Once you understand the changes to the services, you will need to read this code. Feel free to peek ahead though if that's how you like to review stuff. 2. There are still a couple of TODOs which will be resolved early next week. They are both related to how we handle context cloning, so a decision is still pending there. Obviously all the files need to be reviewed, but the remaining files should be fairly mechanical/straight-forward. --- **Checklist** Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review. - [x] Changes are compatible[^1] - [x] Documentation[^2] completed - [x] Performance impact assessed and acceptable - Tests added and passing[^3] - [x] Unit Tests - [x] Integration Tests - ~[ ] Manual Tests~ **Exceptions** *Note any exceptions here* **Notes** [^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. --------- Co-authored-by: Nicholas Cioli <nicholas.cioli@apollographql.com> Co-authored-by: Edward Huang <edward.huang@apollographql.com>
This adds a new `sha256::digest` function to Rhai to enable hash values. Fixes apollographql#4939 <!-- start metadata --> --- **Checklist** Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review. - [x] Changes are compatible[^1] - [x] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [x] Unit Tests - [ ] Integration Tests - [ ] Manual Tests
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
…apollographql#4963) Define the HTTP status code 504 per the [implementation]. [implementation]: https://github.com/apollographql/router/blob/ab069ef2df14d41c37b8087f4aa9a3b60fc38242/apollo-router/src/plugins/traffic_shaping/timeout/error.rs#L28
…on_mode (apollographql#4964) Fixup of apollographql#4551 Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Add instruments page to left-nav, and update related pages.
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
During testing we found an existing issue with batching support which causes the router to panic if an empty batch is submitted to the router. This is only a problem if batching support is enabled. We now explicitly check for empty batches and return a helpful error message if they are detected.
Two of my recent changes had sloppy headers.
This makes it possible to have different coprocessor URLs per stage. The initial URL configuration still serves as a global default, but it can be overridden per stage Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com> Co-authored-by: Jeremy Lempereur <jeremy.lempereur@iomentum.com>
This was incorrectly using `APOLLO_KEY` rather than `TEST_APOLLO_KEY`,
which messes up local dev for most people.
In addition, the test had not been updated when the metric changed name
a while back so was not actually being exorcised on CI.
<!-- start metadata -->
---
**Checklist**
Complete the checklist (and note appropriate exceptions) before the PR
is marked ready-for-review.
- [ ] Changes are compatible[^1]
- [ ] Documentation[^2] completed
- [ ] Performance impact assessed and acceptable
- Tests added and passing[^3]
- [ ] Unit Tests
- [ ] Integration Tests
- [ ] Manual Tests
**Exceptions**
*Note any exceptions here*
**Notes**
[^1]: It may be appropriate to bring upcoming changes to the attention
of other (impacted) groups. Please endeavour to do this before seeking
PR approval. The mechanism for doing this will vary considerably, so use
your judgement as to how and when to do this.
[^2]: Configuration is an important part of many changes. Where
applicable please try to document configuration examples.
[^3]: Tick whichever testing boxes are applicable. If you are adding
Manual Tests, please document the manual testing (extensively) in the
Exceptions.
Co-authored-by: bryn <bryn@apollographql.com>
Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com>
### Type conditioned fetching ([PR apollographql#4748](apollographql#4748)) Type conditioned fetching When querying a field that is in a path of 2 or more unions, the query planner was not able to handle different selections and would aggressively collapse selections in fetches yielding an incorrect plan. This change introduces an experimental configuration option to enable type conditioned fetching: ```yaml experimental_type_conditioned_fetching: true # false by default ``` By [@o0Ignition0o](https://github.com/o0Ignition0o) in apollographql#4748
Added note to [Compression](https://deploy-preview-4974--apollo-router-docs.netlify.app/configuration/traffic-shaping#compression-1) explaining Apollo Server doesn't support `br` compression
This resolves an issue where fragments were always being scored as
costless. The fragment test is now updated to ensure nontrivial
fragments (ie. fragments containing objects) receive a nontrivial score.
<!-- start metadata -->
---
**Checklist**
Complete the checklist (and note appropriate exceptions) before the PR
is marked ready-for-review.
- [X] Changes are compatible[^1]
- [ ] Documentation[^2] completed
- [ ] Performance impact assessed and acceptable
- Tests added and passing[^3]
- [X] Unit Tests
- [ ] Integration Tests
- [ ] Manual Tests
**Exceptions**
*Note any exceptions here*
**Notes**
[^1]: It may be appropriate to bring upcoming changes to the attention
of other (impacted) groups. Please endeavour to do this before seeking
PR approval. The mechanism for doing this will vary considerably, so use
your judgement as to how and when to do this.
[^2]: Configuration is an important part of many changes. Where
applicable please try to document configuration examples.
[^3]: Tick whichever testing boxes are applicable. If you are adding
Manual Tests, please document the manual testing (extensively) in the
Exceptions.
Fixes the json schema for conditionals.
The following config was not valid even though it should have been:
```yaml
telemetry:
instrumentation:
spans:
mode: deprecated
router:
attributes:
http.request.method: true
http.response.status_code: true
url.path: true
"http.request.header.x-my-header":
request_header: "x-my-header"
"http.request.header.x-not-present":
request_header: "x-not-present"
default: nope
"http.request.header.x-my-header-condition":
request_header: "x-my-header"
condition:
eq:
- response_header: "head"
- "test"
```
---------
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: bryn <bryn@apollographql.com>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
…5019) Before we implement a directive to indicate paging in lists, we are using a statically defined assumed size for lists returned in each response. Since there's no real one-size-fits-all value for this, the initial setup will require users to set an assumed list size in the configuration for the static cost estimator. <!-- Fixes [ROUTER-239](https://apollographql.atlassian.net/browse/ROUTER-239) --> <!-- start metadata --> --- **Checklist** Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review. - [X] Changes are compatible[^1] - [ ] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [X] Unit Tests - [ ] Integration Tests - [ ] Manual Tests **Exceptions** *Note any exceptions here* **Notes** [^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. [ROUTER-239]: https://apollographql.atlassian.net/browse/ROUTER-239?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
In the same spirit as the existing Apollo Uplink schema automation which exists in this [file]. This will only allow one PR at a time for this branch name, and only commit changes (and update that branch) when there is a change. [file]: https://github.com/apollographql/router/actions/workflows/update_uplink_schema.yml --------- Co-authored-by: Simon Sapin <simon@apollographql.com>
…raphql#5031) We'll have a GitHub Action do the maintenance on this file, rather than having a test remind us that it's stale. The test results in all PRs (and all downstream users of this repository) suddenly getting failing tests every time our infra-team deploys a new version of the proto, whereas the GitHub Action can be a much more controlled burn. The GitHub action that replaces this is in [apollographql#5030], and we will merge this test just as soon as that is validated. [apollographql#5030]: apollographql#5030
Traffic shaping is always instantiated since apollographql#3330 --------- Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com> Co-authored-by: Maria Elisabeth Schreiber <maria.schreiber@apollographql.com> Co-authored-by: Jesse Rosenberger <git@jro.cc> Co-authored-by: Edward Huang <edward.huang@apollographql.com>
This PR adds selector that will be used for displaying cost metrics on
the router.
A separate PR will be raised for query depth and height under a
different category.
```yaml
telemetry:
instrumentation:
instruments:
supergraph:
cost.actual: true
cost.delta: true
cost.estimated: true
```
In addition the following selectors are introduced:
* cost.estimated
* cost.actual
* cost.delta
* cost.result
This allow you to attach cost related data to spans instruments or
events.
There is a lifecycle issue present in this PR which prevents cost.actual
and cost delta from functioning correct that we will tackled separately.
This is because supergraph response happens before the response payload
has been returned.
<!-- start metadata -->
---
**Checklist**
Complete the checklist (and note appropriate exceptions) before the PR
is marked ready-for-review.
- [ ] Changes are compatible[^1]
- [ ] Documentation[^2] completed
- [ ] Performance impact assessed and acceptable
- Tests added and passing[^3]
- [ ] Unit Tests
- [ ] Integration Tests
- [ ] Manual Tests
**Exceptions**
*Note any exceptions here*
**Notes**
[^1]: It may be appropriate to bring upcoming changes to the attention
of other (impacted) groups. Please endeavour to do this before seeking
PR approval. The mechanism for doing this will vary considerably, so use
your judgement as to how and when to do this.
[^2]: Configuration is an important part of many changes. Where
applicable please try to document configuration examples.
[^3]: Tick whichever testing boxes are applicable. If you are adding
Manual Tests, please document the manual testing (extensively) in the
Exceptions.
---------
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: bryn <bryn@apollographql.com>
Add changelog entry for apollographql#4956 and apollographql#4987 --------- Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com> Co-authored-by: Bryn Cooke <BrynCooke@gmail.com>
Surprisingly, the most expensive part of running tests in the router is in JSON schema compilation. Every time we validate a configuration, we generate the JSON configuration schema (which is about 31k lines at this point) then compile a JSONSchema structure used to validate the configuration. This computation can be done once per execution without losing anything, as it only depends on the configuration schema, which is generated from the router's code and native plugins.
…aphql#5040) This prevents any possibility of port clash, and also doesn't risk the situation where the OS doesn't release the socket in time before it is reused by the router. <!-- start metadata --> --- **Checklist** Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review. - [ ] Changes are compatible[^1] - [ ] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [ ] Unit Tests - [ ] Integration Tests - [ ] Manual Tests **Exceptions** *Note any exceptions here* **Notes** [^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. Co-authored-by: bryn <bryn@apollographql.com>
Follow-up to the v1.45.1 being officially released, bringing version bumps and changelog updates into the dev branch. Separating this from apollographql#5036 to solve the conflicts between main and dev without making an additional commit to main
…graphql#5034) Without filtering the query hashes during batch creation we could end up in a situation where we have additional query hashes in the batch. This manifests itself by batch queries failing with query hashes appearing as committed without ever having been registered in a batch. Filtering during batch creation is now matching the filtering at subgraph coordination.
…runs (apollographql#5023) As tends to be the case, our CI testing times have been driven up over time. While we currently have broad-stroke measurements on the CI pipeline, we don't yet have per-test insights. This makes it difficult to commit time to specific efforts, or measure their improvement. Further, the ergonomics over using the failed tests interface on CircleCI have been hindered by the lack of test reporting through well-defined testing output artifacts like Junit, popular with most other languages. Rust core hasn't yet promoted its structured `cargo test` output into a stable build which — if we wanted to measure tests by producing anything remotely coercible into JUnit — would mean we'd have to run `+nightly` runs of the tests. Using the `nightly` build of `cargo test` to get almost (but still not) JUnit seems unnecessarily risky. Given that this feature hasn't promoted from `+nightly` in what must be plural years and the allure of other more feature-complete testing tools like [Nextest](https://nexte.st/) — I decided to give Nextest a quick try. The quick test is seemingly successful and validating: It did not show any degradation in test execution time, is already showing promising nice wins in CircleCI interface experience, seems like an improvement to the CLI experience (image below, but also by [highlighting specific test failures in the UI](https://app.circleci.com/pipelines/github/apollographql/router/20805/workflows/09ba269e-b917-4d2e-ad52-68e80e14ab94/jobs/140871/tests)), unlocks other capabilities (like automatic retries on a per-test basis), and didn't require passing custom thread flags ([perhaps due to a better model for test execution](https://nexte.st/book/how-it-works)?).  ### Local vs CI / How to enable nextest locally Nextest is only used if it is installed and the decision to do so is made inside of `cargo xtask test` based on the presence of `cargo-nextest`. If `cargo-nextest` is **not** installed, then the existing `cargo test` is used as a fall-back. On CI, it is installed and thus used.
Updates our notion of `current` to the latest version `windows-server-2019-vs2019:2024.02.21` but _pins_ it, so it doesn't change randomly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description here
Fixes #issue_number
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩