Merged
Conversation
…lue 0 will work properly
Add suggested change per PR comments Co-authored-by: Nishchal Gautam <cyberhck@users.noreply.github.com>
Due to the differences between JS and RS graph structures (JS is always topologically sorted) we occassionally end up with different parallel fetch node order....
This fixes the cache integration tests that were flaky. This is due in part to all the tests using the same subgraph names and types, on the same redis instance. This applies the following fixes: * use text based logging instead of JSON for more readability * unique query names per test * unique subgraph names per test * remove cached data at the end of the test (not needed for the CI? but it helps for local tests) * raise the SCAN command's COUNT argument (max number of keys returned by one invocation of scan) from 10 to 100
If we are requesting entities from a subgraph, where some of them are present in cache, and the subgraph is unavailable (ex: network issue), we want to return a response with the entities we got from the cache, other entities nullified, and an error pointing at the paths of unavailable entities. Co-authored-by: Bryn Cooke <BrynCooke@gmail.com>
- Generates a string representing the graph in GraphViz dot format. - Mainly for debugging purposes.
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com> Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com> Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com> Co-authored-by: Edward Huang <edward.huang@apollographql.com> Co-authored-by: Bryn Cooke <BrynCooke@gmail.com>
Co-authored-by: bryn <bryn@apollographql.com> Co-authored-by: Edward Huang <edward.huang@apollographql.com>
…xSet` to avoid non-determinism (#5827)
When parsing `@requires` field set selection we need to use supergraph schema instead of a target subgraph schema.
Session counting incorrectly included connections to the health check or other non-graphql connections. This is now corrected so that only connections to the main graphql port are counted. Warnings about file handle shortages are now handled correctly as a global resource.
The listener had its own custom rate limiting for log messages. The router comes with a standard mechanism for rate limiting log messages. Remove the custom rate limiting mechanism and advised in the changelog that standard rate limiting configuration should be used.
tayrrible
requested review from
a team,
SimonSapin,
TylerBloom,
dariuszkuc,
duckki,
goto-bus-stop,
lrlna and
sachindshinde
as code owners
|
CI performance tests
|
lennyburdette
approved these changes
Aug 16, 2024
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
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. ↩