Skip to content
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 storedRequestTimeoutMillis as cutomizable config variable #1533

Closed
wants to merge 1 commit into from

Conversation

amaurybrisou
Copy link

Set storedRequestTimeoutMillis as global config variable, allowing http fetchers timeout customization through stored_requests.http.fetcher_timeout config.
#1527

Copy link
Contributor

@SyntaxNode SyntaxNode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the contribution. I suggested a different config location. Do you think it's possible to add a unit test for the endpoints?

@@ -863,6 +863,7 @@ func SetupViper(v *viper.Viper, filename string) {
v.SetDefault("stored_requests.postgres.poll_for_updates.amp_query", "")
v.SetDefault("stored_requests.http.endpoint", "")
v.SetDefault("stored_requests.http.amp_endpoint", "")
v.SetDefault("stored_requests.http.fetcher_timeout", 50)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't the correct place to configure the timeout. This is an endpoint timeout for calling whatever stored request fetcher is in use rather than a configuration of the http fetcher. I recommend something along the lines of stored_request_timeout_ms at the root.

IMHO, this follows the pattern of amp_timeout_adjustment_ms and video_stored_request_required.

@@ -226,7 +224,7 @@ func (deps *endpointDeps) parseRequest(httpRequest *http.Request) (req *openrtb.
}
}

timeout := parseTimeout(requestJson, time.Duration(storedRequestTimeoutMillis)*time.Millisecond)
timeout := parseTimeout(requestJson, time.Duration((*deps.cfg).StoredRequests.HTTP.FetcherTimeout)*time.Millisecond)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no need to dereference a copy of the config. You could just do deps.cfg.StoredRequestTimeoutMS.

@amaurybrisou
Copy link
Author

Thank you for the contribution. I suggested a different config location. Do you think it's possible to add a unit test for the endpoints?

Sure I can do that but where ? on the stored_requests/fetcher_test.go level or individual endpoints ?

stored_requests/fetcher_test.go doesn't look a good place because it's mainly for cache tests and cache will obviously break the test.
stored_requests/multifetcher_test.go ?

Thanks

@SyntaxNode
Copy link
Contributor

Sure I can do that but where ? on the stored_requests/fetcher_test.go level or individual endpoints ?

At the individual endpoint level. The change you're making doesn't change the fetcher code, it's the call site in the endpoints when calling into the fetcher code.

Don't worry if the code is too hard to reach with a unit test. I just think it's worth a check. The change is straight forward enough that major rework of the endpoint isn't necessary to add a test.

@amaurybrisou
Copy link
Author

Ok these are various things to to, I'll do it asap

@SyntaxNode
Copy link
Contributor

@amaurybrisou Friendly reminder about this PR.

@amaurybrisou
Copy link
Author

Yep I'm sorry, I don't have the time to code all the tests and it has quite a lot. I will asap hopefully

@SyntaxNode
Copy link
Contributor

SyntaxNode commented Oct 28, 2020

Yep I'm sorry, I don't have the time to code all the tests and it has quite a lot. I will asap hopefully

No worries. Just want to keep it on your radar. I didn't mean to overwhelm you with the ask for tests. If it's simple to do, then great. If it will be too much work to find a way to test, then I'll consider that beyond the scope of this PR as there are no existing tests covering this value.

@stale
Copy link

stale bot commented Nov 7, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 7, 2020
@stale stale bot closed this Dec 19, 2020
@holms
Copy link

holms commented Feb 4, 2022

@amaurybrisou maybe you could please take a look at this again, or I can submit new PR? I mean having 50ms for external endpoint of stored requests, which can be like any IAAS or database-as-a-service out is a bit strange don't you think? Also we have millions of configs in there.. 50ms is a bit too harsh.

@SyntaxNode
Copy link
Contributor

@holms This PR was automatically closed by our stalebot when the original author stopped responding. We have no issue with adding this feature if you'd like to take over development and open a new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants