fix: convert requestOptions.timeout to milliseconds for OpenAI SDK - #12451
Closed
ScrewTSW wants to merge 5 commits into
Closed
fix: convert requestOptions.timeout to milliseconds for OpenAI SDK#12451ScrewTSW wants to merge 5 commits into
ScrewTSW wants to merge 5 commits into
Conversation
Contributor
|
All contributors have signed the CLA ✍️ ✅ |
Author
|
I have read the CLA Document and I hereby sign the CLA |
The JetBrains test job pinned FFmpeg 7.1, but BtbN/FFmpeg-Builds keeps only the most recent release branches under its rolling `latest` tag and has since dropped the 7.1 artifacts, so the asset URL the action builds now 404s. `AnimMouse/setup-ffmpeg` pipes `wget -qO-` straight into `tar -xJ`, so the 404 body reaches tar rather than an archive and the real cause is reported one stage downstream as "xz: (stdin): File format not recognized". The step fails in 240ms, before Gradle, prepackage, the binary build or the tests run, so no JetBrains tests execute at all. Bump the pin to 8.1 and add a preflight check that verifies the artifact exists first, failing with an explicit annotation naming the missing URL so the next branch rotation is self-explaining. The version is a single action input, so the pin lives in one place.
The `build-and-upload-vsix` matrix was capped at 10 minutes, which cold
Windows and macOS builds of this monorepo routinely exceed. Observed job
durations against the cap:
linux/x64 4m23s ok
win32/x64 9m20s ok (40s margin)
darwin/arm64 8m18s ok
win32/x64 10m41s killed
darwin/arm64 10m16s killed
GitHub reports a timeout as `cancelled`, not `failure`, and kills the job
mid-step. Because the cache save in the composite action's post phase is
the last thing running at teardown, it is what surfaces in the UI - which
made this look like a Windows npm caching bug rather than a timeout.
Whichever platform is slowest on a given run is the one that dies, so the
failure moves between win32 and darwin.
Raising the cap only stops the truncation. Warm builds are unaffected; the
underlying cause of slow cold builds is that the three node_modules caches
in .github/actions/build-vscode-extension share a `${{ runner.os }}-node-`
key prefix with no restore-keys, so any lockfile change is a total miss and
forces a full `npm ci`. That is left for a follow-up.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* chore: drop Node v18/v20, raise minimum to lts/v22 * fix: bump sqlite3 to v6 to unblock native build on Node 22 * fix: use documented `macos` platform id for pkg target * fix(vscode): derive sqlite3 prebuild URL from installed version * fix(vscode): validate sqlite3 target, drop shell from download Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…OpenAI SDK The OpenAI JS SDK expects timeout in milliseconds, but users configure requestOptions.timeout in seconds. Passing the value directly results in sub-second timeouts (e.g. timeout: 300 becomes 300ms instead of 5 minutes), causing "Connection error" for any model that takes more than a fraction of a second to respond. Fixes continuedev#12450
ScrewTSW
force-pushed
the
12450-fix-timeout-unit-conversion
branch
from
August 19, 2026 11:40
4a456a4 to
f2dbafb
Compare
Addresses review feedback from CodeRabbit and Copilot on #8. The truthiness check treated a configured `timeout: 0` as unset and passed `undefined`, so the SDK applied its 10-minute default instead. `timeout` is `z.number().optional()` with no positivity constraint, so 0 is schema-valid and reaches this code. Use a nullish check, matching how both sides already treat 0 as a real value: the SDK resolves its default with `options.timeout ?? DEFAULT_TIMEOUT`, and our own getAgentOptions uses `?? TIMEOUT`. Adds OpenAI.test.ts covering the seconds→ms conversion, the zero case, and the unset case. Verified the zero test fails against the previous code (expected 0, got 600000) rather than merely passing after the fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
requestOptions.timeoutis configured in seconds by users, but the OpenAI JS SDK constructor expects milliseconds. The value was passed through without conversion, sotimeout: 300(5 minutes) became a 300ms timeout.One-line fix: multiply by 1000 before passing to the SDK.
Fixes #12450
Likely root cause for many reports in #11818
Checklist
Tests
Tested with local llama.cpp models behind an orchestrator (
timeout: 300in config). Before: immediate "Connection error". After: requests complete normally with model load + prompt eval taking 30-60s.Summary by cubic
Convert
requestOptions.timeout(seconds) to milliseconds before passing to theopenaiclient. Fixes unintended sub-second timeouts and restores expected behavior for long-running requests.requestOptions.timeoutby 1000 in theOpenAIApiconstructor sotimeout: 300becomes 300000 ms, not 300 ms.Written for commit 4a456a4. Summary will update on new commits. Review in cubic