-
Notifications
You must be signed in to change notification settings - Fork 5
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
Add resolver timeout #19
base: joysteam
Are you sure you want to change the base?
Conversation
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:
|
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. |
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_CONCURRENCY
set 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.