Open
Conversation
Collaborator
Author
|
I've been trying to test the QN build for a few hours, but it turns out to be a lot more difficult than I expected.
Here's the way I went at it:
The builds kind of succeeds but the Finally the Graphql server crashes with: |
Collaborator
Author
|
So there was 2 issues:
I ran the network tests with the build and everything passed. @zeeshanakram3 please have a look when you get the time. |
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
2 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.
Address the part 2 of Joystream/joystream#5088
It's a bit hacky but the only efficient way I found to really stop the resolvers (and not having queries still happening in the background) is through the DataLoader middleware. The main reason is that this middleware is responsible for the n+1 problem so other middlewares wouldn't be able to abort the queries the DataLoader initiate.
Also it has to split the relation queries into chunks instead of running everything in parallel (
WARTHOG_RELATION_CONCURRENCYset the size of the chunk). It might affect the performance of slow queries but it could also free some db connection for other clients so overall I think it's not too bad.I updated typescript in order to use
AbortSignal.timeout(reqTimeout)because I couldn't figure out a way to clear timeout from the more traditionalsetTimeout, becausenext()resolves before the relations queries (which is weird because when running a middleware after this one it doesn't resolves until all fields have resolves 🤷)FYI I tested it with slow "horizontal" queries like
distributionBuckets(where: { id_eq: "0:1" }) { bags { objects { id } }but also huge queries with a lot of depth. It does work in both case because even with the deeper queries the first resolvers dataloaders get's called for all deeper entities. However these deep queries will return some of the data it got before the timeout and and errors for every entities which timed out.