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

Per-request timeouts #357

Open
joshtriplett opened this issue Apr 2, 2023 · 1 comment
Open

Per-request timeouts #357

joshtriplett opened this issue Apr 2, 2023 · 1 comment

Comments

@joshtriplett
Copy link
Member

I'd love to set a timeout on a per-request basis that overrides the timeout in the config. That way, individual requests can have a default timeout, while known long-running requests can disable the timeout.

@yoshuawuyts
Copy link
Member

This is not a perfect answer, but using something like futures-time (blog) could perhaps do what you want it to:

use futures_time::prelude::*;
use futures_time::time::Duration;

let res = surf::get("api.example.com")
    .timeout(Duration::from_secs(2))    // provided by futures-time
    .await??;                           // the first `?` is surf, the second `?` is futures-time

It only allows defining timeouts shorter than the default; if they're longer the default will run first. So it may not fully suit your use case. But it might be a good way to get things working in the shorter-term without needing to modify surf directly.

There is probably a bigger question here too about what the right ways of structuring timeout hierarchies are, and for example a non-async version of surf should reason about timeouts (if at all). Buy maybe it's simply enough to say: "if you have an arbitrary operation you want to be able to time-out, you should call the timeout method on the future". I'm not sure heh.

Anyway, I hope this is helpful!

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

No branches or pull requests

2 participants