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

Add configurable timeout to API config #24

Merged
merged 3 commits into from
Jul 19, 2024

Conversation

lpchaim
Copy link
Contributor

@lpchaim lpchaim commented Jun 15, 2024

I'm currently experimenting with ollama on a not too powerful laptop, so I stumbled upon #22 pretty quickly.
Seeing as I liked the simplicity of smartcat and the fact it's Rust based, I figured I'd try my hand at adding an optional timeout parameter.

I implemented the "timeout" field in ApiConfig, and made it optional. I also made it so the reqwest client is instantiated through its builder so that the timeout can be specified. It could also be passed on the individual request, but since that form doesn't take an Option as a parameter, I figured this would be a bit cleaner.

Right now, the logic works as such:

  • If it's passed as a positive integer, the timeout is set as the parameter's value in seconds
  • If it's passed as zero, the timeout is disabled entirely
  • If it's omitted, it defaults to the standard 30 seconds

Copy link
Owner

@efugier efugier left a comment

Choose a reason for hiding this comment

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

Hey, that's awesome thanks a lot!

I can merge this as is and implement the default behavior change on my end or let you do it, you tell me what you prefer!

@@ -64,6 +64,8 @@ pub struct ApiConfig {
pub default_model: Option<String>,
#[serde(skip_serializing_if = "Option::is_none")]
pub version: Option<String>,
#[serde(skip_serializing_if = "Option::is_none")]
pub timeout: Option<u16>,
Copy link
Owner

@efugier efugier Jun 17, 2024

Choose a reason for hiding this comment

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

quibble:

Suggested change
pub timeout: Option<u16>,
/// client timeout in seconds
pub timeout: Option<u16>,

Was unsure about renaming that to timeout_seconds or adding a comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I'd vote for timeout_seconds myself since then the meaning is clear and unambiguous on the config file itself

Copy link
Owner

Choose a reason for hiding this comment

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

Sounds great to me!

@@ -94,13 +96,23 @@ impl ApiConfig {
.unwrap_or_default()
}

pub fn get_timeout(&self) -> Option<Duration> {
Copy link
Owner

Choose a reason for hiding this comment

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

Small comment on the default behavior: I'd prefer to have the default method of the API config set it to 30s and use None for actual no timeout instead of zero.

I find less confusing to rely on the type system when possible instead of defining arbitrary behavior 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, that makes sense. I'll try and get the changes in within the next day or so

Copy link
Owner

Choose a reason for hiding this comment

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

Thanks a ton!

@lpchaim
Copy link
Contributor Author

lpchaim commented Jun 17, 2024

Hey, no worries! Always happy to chip in :)

Anyway, I'd love to give the changes a go on my end, if only to practice my real world Rust a little more. If it ends up not to your taste afterwards, I wouldn't mind at all if you took over and added on top of my modifications. Does that work?

Change the default timeout to 30 and treat its omission as indefinite
timeout

Rename timeout to timeout_seconds
@lpchaim
Copy link
Contributor Author

lpchaim commented Jun 18, 2024

Alright, I've implemented the requested changes. These should cover what we've discussed, unless I misunderstood something.

Copy link
Owner

@efugier efugier left a comment

Choose a reason for hiding this comment

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

Hey, awesome work!

I am so sorry I seem to have the notification saying you iterated, last weeks were a bit hectic...

@lpchaim
Copy link
Contributor Author

lpchaim commented Jul 18, 2024

Hey, no worries! Lmk if you'd prefer I squashed the commits together or anything like that and I'll get to that ASAP.

@efugier
Copy link
Owner

efugier commented Jul 19, 2024

It's perfect like that!

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

Successfully merging this pull request may close these issues.

2 participants