-
Notifications
You must be signed in to change notification settings - Fork 44
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
Set maxQueryExecutionTime
through an environment variable
#538
base: master
Are you sure you want to change the base?
Conversation
@kdembler I had made a mistake on the server config. Now I made a bunch of tests and even though according to the telemetry queries keep on going after the request timed out especially when the timeout is less than 300 ms, it looks like it's working. But the best would be to identify one of the slow queries thank to the telemetry and see what happens when the timeout is set. |
Also I set |
Hey @kdembler. You were right: I tested the express middleware with a partially processed mainnet, which made it clear that the flow wasn't stopping at all after the request timed out. So I tried a similar approach but using a type-graphql global middleware and this time the flow does appear to be aborted. It did take a few 100s of ms after the timeout but with a query that would take ~800ms to execute (without timeout): the last event reported by the telemetry was at ~400ms (for a timeout of 200ms) so it seems to be working now. |
That was just due to a the last rename of Still I'm seeing some strange results so I'll look some more on Monday. |
…custom maxQueryExecutionTime affects: @joystream/hydra-cli Set \`maxQueryExecutionTime\` through an environment variable
00e6ca4
to
d4a124a
Compare
maxQueryExecutionTime
through an environment variable
Address part of Joystream/joystream#5088
IMO rate limiting (DDOS prevention...) should be taken cared of by specialized tools (e.g Fail2ban).
affects: @joystream/hydra-cli
Add optional timeout for gql request and db queries