-
Notifications
You must be signed in to change notification settings - Fork 194
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
feat: Add option to pass external contexts into Go SDK's HTTP calls #1475
base: main
Are you sure you want to change the base?
Changes from all commits
cbe955e
d348f80
8fcc052
1154ed8
673a3ea
81ac004
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -118,3 +118,57 @@ func main() { | |
} | ||
} | ||
``` | ||
### Custom Context | ||
|
||
If you want even greater control over the lifecycle of the HTTP requests consider providing a [context](https://pkg.go.dev/context). Contexts can be set for all requests or per request. They can be combined with the timeout options mentioned in the previous section to fine-tune the lifecycle of your requests. | ||
|
||
If you wish to include timeout functionality in your custom context then you should leverage [context.WithTimeout](https://pkg.go.dev/context#WithTimeout). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Change to:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See my previous comment - this is inaccurate. |
||
|
||
> Note: Custom contexts will be used as the parent context for any timeout you set as specified in the previous section. If the parent context gets cancelled it will propagate to the child context, but if the timeout context times out it does not propagate to the parent context. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure what this means? Can we remove this if we're going with the new behavior? |
||
|
||
#### Custom Context for all requests | ||
|
||
Follow the example code snippet below if you want all requests to use the same parent context: | ||
|
||
```go | ||
import "context" | ||
|
||
func main() { | ||
// sets a timeout of 5 minutes | ||
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute) | ||
defer cancel() | ||
|
||
cfg, err := rtl.NewSettingsFromFile("path/to/looker.ini", nil) | ||
cfg.Context = ctx | ||
|
||
session := rtl.NewAuthSession(cfg) | ||
sdk := v4.NewLookerSDK(session) | ||
} | ||
``` | ||
|
||
> Note: A context set here will become the parent context for all API calls as well as all requests to fetch/refresh oauth tokens, which are normally completely isolated from contexts set via the Timeout property. In this case the token refresh requests and each individual API call will share a common parent context. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Change to
|
||
|
||
#### Custom Context per request | ||
|
||
Follow the example here to set a context for a specific request. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also add "For the specific request, the custom context will replace the custom context set for all requests in the previous "Custom Context for all requests" section." |
||
|
||
> Note: This will be used as the parent context for any timeout setting you've specified for API calls. If you've set contexts in both your API config and in the request options the request options context will be used instead. Background requests to fetch/refresh oauth tokens will NOT use a context set via request options - it will default to use a generic background context or, if you've also set a context in the API config it will still use that as specified in the previous section. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can be removed |
||
|
||
```go | ||
import "context" | ||
|
||
func main() { | ||
// sets a timeout of 5 minutes | ||
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute) | ||
defer cancel() | ||
|
||
cfg, err := rtl.NewSettingsFromFile("path/to/looker.ini", nil) | ||
session := rtl.NewAuthSession(cfg) | ||
sdk := v4.NewLookerSDK(session) | ||
|
||
sdk.Me("", &ApiSettings{Context: ctx}) | ||
} | ||
``` | ||
|
||
> Note: Setting a context per request will NOT affect the context used for the background token fetching requests. If you have also set a context for all requests as mentioned above then that context | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also add "If you set a custom context for a specific request, the SDK will ignore any timeout described in the previous Timeout section for the specific request. You must set the timeout with the custom context for the specific request." There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This isn't true - request timeouts will still apply - any specified context simply becomes the parent of the timeout request. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Replace with
|
||
will still be used for the token requests, otherwise the SDK will fall back on using a completely separate context for the token fetching requests. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -67,8 +67,13 @@ func NewAuthSessionWithTransport(config ApiSettings, transport http.RoundTripper | |
AuthStyle: oauth2.AuthStyleInParams, | ||
} | ||
|
||
bgCtx := context.Background() | ||
JCPistell marked this conversation as resolved.
Show resolved
Hide resolved
|
||
if config.Context != nil { | ||
bgCtx = config.Context | ||
} | ||
|
||
ctx := context.WithValue( | ||
context.Background(), | ||
bgCtx, | ||
oauth2.HTTPClient, | ||
// Will set "x-looker-appid" Header on TokenURL requests | ||
&http.Client{Transport: appIdHeaderTransport}, | ||
|
@@ -123,16 +128,24 @@ func (s *AuthSession) Do(result interface{}, method, ver, path string, reqPars m | |
} | ||
} | ||
|
||
// create request context with timeout | ||
var timeoutInSeconds int32 = 120 //seconds | ||
parent := context.Background() | ||
if s.Config.Context != nil { | ||
parent = s.Config.Context | ||
} | ||
if options != nil && options.Context != nil { | ||
parent = options.Context | ||
} | ||
|
||
// create request context with timeout from options or else config or else 120 seconds | ||
var timeoutInSeconds int32 = 120 | ||
if s.Config.Timeout != 0 { | ||
timeoutInSeconds = s.Config.Timeout | ||
} | ||
if options != nil && options.Timeout != 0 { | ||
timeoutInSeconds = options.Timeout | ||
} | ||
|
||
ctx, cncl := context.WithTimeout(context.Background(), time.Second*time.Duration(timeoutInSeconds)) | ||
ctx, cncl := context.WithTimeout(parent, time.Second*time.Duration(timeoutInSeconds)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the parent context has a different timeout, what's the expected behavior here? Does it go with the shorter one? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not exactly. If the parent hits its cancellation condition (e.g. a timeout) first then the cancellation propagates to the child. However, If the child cancels first, it depends on how that specific error is handled... perhaps the request retries, perhaps the error is passed to the calling function, in which case most of the time the function fails and the parent context then cancels, which propagates the cancellation to all other goroutines, etc etc. Basically this approach means you can have an overall timeout set by a parent, but each individual request running in a goroutine can also have its own timeout... this avoids the scenario where you set a 60min overall timeout, but one bad request has to wait the entire 60m to time out and fail. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think an easier to understand behavior would be: Trying to document/understad the how timeout works with context/config/options is confusing and harder to test. Plus if dev is using contexts, they are a power user who has way more levers to pull, and should know about using timeouts in contexts. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I disagree - see my previous comment. I actually think this is easier to document and the tests are already in place. |
||
defer cncl() | ||
|
||
// create new request | ||
|
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.
Change to: