fix: match timeout behaviour with docs

[elianiva]

Related GitHub Issue

Closes: #7366

Roo Code Task Context (Optional)

Description

This PR fixes timeout to match the docs. This PR makes it so that 0 actually disables the timeout by setting it to max 32 int value (2^31 - 1).

I wonder if I should change the getApiRequestTimeout instead to return that value? I keep all of it at the providers right now. Tell me if that is more preferable than the current implementation.

Test Procedure

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

@elianiva

---

Important

Fix timeout behavior to match documentation by setting a timeout of 0 to the maximum safe integer value, applied across multiple API providers.

• Behavior:
  • Updates getApiRequestTimeout() in timeout-config.ts to return 2147483647 for a timeout of 0, effectively disabling the timeout.
  • Applies updated timeout logic to API clients in anthropic.ts, base-openai-compatible-provider.ts, bedrock.ts, cerebras.ts, huggingface.ts, lm-studio.ts, ollama.ts, openai-native.ts, openrouter.ts, qwen-code.ts, requesty.ts, router-provider.ts, and xai.ts.
• Tests:
  • Updates timeout-config.spec.ts to test new behavior for zero and negative timeout values, ensuring they return the safe maximum value.
• Misc:
  • Minor refactoring in timeout-config.ts for clarity and consistency.

^{This description was created by for 83aebe4. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Thank you for your contribution! I've reviewed the changes and found some issues that need attention before this can be merged.

[roomote]

Important: The test file src/api/providers/__tests__/openai-timeout.spec.ts needs to be updated. Line 140 currently expects timeout to be 0 when getApiRequestTimeout returns 0, but with your changes it should now expect 2147483647. This will cause test failures if not updated.

You may also want to add tests to verify that providers correctly transform 0 to 2147483647 for better test coverage of this new behavior.

[elianiva]

on second thought, there's no reason not to do that, brb will update it

[elianiva]

@hannesrudolph was this closed on purpose?

[hannesrudolph]

@hannesrudolph was this closed on purpose?

Yeah it's stale. You said you were going today and didn't so I assumed you abandoned it.

[elianiva]

@hannesrudolph was this closed on purpose?

Yeah it's stale. You said you were going today and didn't so I assumed you abandoned it.

oh sorry for the ambiguity / lack of clarification, per my last commit this PR is actually ready to review / merge :)
i should probably add comments instead of just leaving it after a commit

[hannesrudolph]

Then reopen it?

[daniel-lxs]

It seems like something broke every test that imports the timeout-config file.

[elianiva]

I've fixed the tests. Two things:

1. We didn't return anything from mocked vscode, I believe it was a leftover from when we were still using jest. The comment said "mock to prevent error". It's no longer needed since we fully support ESM now for the tests.
2. I clarified the test label to prevent confusion in the future since we don't actually return 0 for "no timeout" but rather returning max value for i32. 0 literally means timeout immediately, which was incorrect before this PR.

[joshuakoh1]

Why is this still not merged?

[peter-ch]

Please merge this, this bug is not a minor inconvenience but a use case blocker.

[joshuakoh1]

Please merge this, this bug is not a minor inconvenience but a use case blocker.

Exactly. This makes the entire software unusable for local models over a BUG. Nobody running SOTA models locally will be able to keep prompt processing under 5 minutes at max context.

[peter-ch]

The caching in LM Studio (llama.cpp) at least allows the big prompts to eventually compute in under 5 minutes, but after multiple retries, so I maxed out the allowed retries and time between them, but this is an ugly workaround and not very reliable.

[joshuakoh1]

This is exactly what's happening for me as well. Using exl3 and eventually after 5-10 retries enough has cached to take under 5 minutes. But this is really stupid behaviour and 10-folds the time wasted for every single request.

[peter-ch]

This is exactly what's happening for me as well. Using exl3 and eventually after 5-10 retries enough has cached to take under 5 minutes. But this is really stupid behaviour and 10-folds the time wasted for every single request.

I found the fix. Switch to Kilo Code and let this thing rot.

[Skelectric]

This is exactly what's happening for me as well. Using exl3 and eventually after 5-10 retries enough has cached to take under 5 minutes. But this is really stupid behaviour and 10-folds the time wasted for every single request.

I found the fix. Switch to Kilo Code and let this thing rot.

Kilo Code has the exact same issue, so what fix did you find?

[peter-ch]

This is exactly what's happening for me as well. Using exl3 and eventually after 5-10 retries enough has cached to take under 5 minutes. But this is really stupid behaviour and 10-folds the time wasted for every single request.

I found the fix. Switch to Kilo Code and let this thing rot.

Kilo Code has the exact same issue, so what fix did you find?

Isn't that issue closed there? That means it used to have the same exact issue, not anymore. I can also confirm it - I enter 86400 in Kilo and it waits hours and hours, definitely something got fixed.

[Skelectric]

This is exactly what's happening for me as well. Using exl3 and eventually after 5-10 retries enough has cached to take under 5 minutes. But this is really stupid behaviour and 10-folds the time wasted for every single request.

I found the fix. Switch to Kilo Code and let this thing rot.

Kilo Code has the exact same issue, so what fix did you find?

Isn't that issue closed there? That means it used to have the same exact issue, not anymore. I can also confirm it - I enter 86400 in Kilo and it waits hours and hours, definitely something got fixed.

Despite the issue being closed, I just confirmed that it's not fixed. I set the API timeout to 86400 seconds in Kilo, generated a 44.6k token conversation, then changed the mode (from Architect to Ask) to force LLM (i'm running unsloth's deepseek-v3.1-terminus q2_k_xl) to reread the conversation in a single request, and it still failed at the 5 minute mark. Version is 4.119.2. It's a bit silly how widespread this bug is - n8n has it too.

Anyway, Belerafon suggested a fix for Roo Code here: #7366 (comment), which I've tested.

Hopefully Roo Code devs properly patch this soon.

[peter-ch]

This is exactly what's happening for me as well. Using exl3 and eventually after 5-10 retries enough has cached to take under 5 minutes. But this is really stupid behaviour and 10-folds the time wasted for every single request.

I found the fix. Switch to Kilo Code and let this thing rot.

Kilo Code has the exact same issue, so what fix did you find?

Isn't that issue closed there? That means it used to have the same exact issue, not anymore. I can also confirm it - I enter 86400 in Kilo and it waits hours and hours, definitely something got fixed.

Despite the issue being closed, I just confirmed that it's not fixed. I set the API timeout to 86400 seconds in Kilo, generated a 44.6k token conversation, then changed the mode (from Architect to Ask) to force LLM (i'm running unsloth's deepseek-v3.1-terminus q2_k_xl) to reread the conversation in a single request, and it still failed at the 5 minute mark. Version is 4.119.2. It's a bit silly how widespread this bug is - n8n has it too.

Anyway, Belerafon suggested a fix for Roo Code here: #7366 (comment), which I've tested.

Hopefully Roo Code devs properly patch this soon.

It definitely works for me, check this out:

Yes, this bug is so bothersome because it makes so much hardware useless and I also happen to own some of that shit hardware. Imagine if this worked, every potato PC could be repurposed as full-time agent working on stuff.