-
Notifications
You must be signed in to change notification settings - Fork 2.8k
add timeout to remote schema calls (close #2501) #2753
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 timeout to remote schema calls (close #2501) #2753
Conversation
|
Deploy preview for hasura-docs ready! Built with commit d39a04c |
|
Review app for commit 3816f3c deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
|
Review app for commit 9910b20 deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
|
Review app for commit 3e3dde0 deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
|
@tirumaraiselvan Can you update the API changes in docs |
|
Review app for commit b48d3d5 deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
server/src-lib/Hasura/HTTP.hs
Outdated
| wreqOptions manager hdrs = | ||
| Wreq.defaults | ||
| & Wreq.headers .~ contentType : userAgent : hdrs | ||
| & Wreq.headers .~ defaultHeaders <> hdrs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don’t we need to avoid adding userAgent here if it’s in hdrs already? I think it’s legal for certain HTTP headers to be specified multiple times, so I imagine wreq will currently just send both. (It’d be nice to be able to have a test case for this, but IIUC it’s not super easy to do with the current test harness?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right! Thanks.
This reverts commit 3e3dde0.
|
Review app for commit 4258210 deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
server/src-lib/Hasura/Events/Lib.hs
Outdated
| [ (CI.mk "Content-Type", "application/json") | ||
| , (CI.mk "User-Agent", "hasura-graphql-engine/" <> T.encodeUtf8 currentVersion) | ||
| ] | ||
| addDefaultHeaders hdrs = defaultHeaders <> rmDefaultHeaders hdrs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lexi-lambda This change has led me to believe that we have HTTP clients which are not using the Hasura.HTTP library basically (event trigger module and remote schema module):
The only modules which seem to be using this are:
Telemetry
Auth
Auth/JWT
CheckUpdates
Is it fine for EventTriggers and RemoteSchemas to maintain their own clients because these might be specific to these modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function appears to prioritize default headers over the headers that were passed in, but the code in GraphQL.Execute appears to prioritize the headers that were passed in over the default headers. Is the difference intentional?
Also, can this code at least share the defaultHeaders declaration with the one in Hasura.HTTP? Having it duplicated in both places seems worth avoiding if we can help it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was my question. Is it worth sharing these tiny functions, when the bulk of the client is specified per module itself? Shouldn't HTTP.Hasura give out a client with these baked in for standard usage? Those who are not using it may do their own thing including defaultHeaders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t know, as I haven’t looked at the code in detail, but my gut instinct is that
-
these modules should probably be using
Hasura.HTTP, -
but if they aren’t, and you don’t want to do the refactoring to make them use it right now, sharing the default headers is an alright first step.
If the first assumption isn’t true, then you could be right, but I’d be surprised if it were. Is there a reason these modules shouldn’t be using the same library?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is any real reason except the library didn't have proper functions to use with Event Triggers. I guess we should make an attempt to consolidate the library then.
Cool, I am just going to share the functions then. Let's do the full consolidation in a separate no-op refactor PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. 👍
|
Review app for commit cd5e656 deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
|
Review app for commit 1bbbc46 deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
|
Review app for commit 1c6285d deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
|
Review app for commit 0c444f6 deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
d39a04c
|
Review app for commit d39a04c deployed to Heroku: https://hge-ci-pull-2753.herokuapp.com |
|
Review app https://hge-ci-pull-2753.herokuapp.com is deleted |
Description
Adds an optional
timeout_secondsargument toadd_remote_schemaAPIAffected components
Related Issues
#2501
Solution and Design
Steps to test and verify
Limitations, known bugs & workarounds