-
Notifications
You must be signed in to change notification settings - Fork 44
Add timeout to http client requests #1351
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Greptile Summary
This PR adds optional timeout functionality to HTTP requests in the WorkOS Node.js SDK to prevent indefinite request hanging. The implementation introduces a timeout parameter to the WorkOSOptions interface, which gets passed through the WorkOS constructor to the FetchHttpClient. The timeout is implemented using the AbortController API to cancel requests that exceed the specified duration (in milliseconds).
The changes integrate seamlessly with the existing architecture - the WorkOS class's creatHttpClient method now passes the timeout option from WorkOSOptions to the FetchHttpClient constructor. The FetchHttpClient creates an AbortController when a timeout is configured, sets up a timer to abort the request after the specified duration, and properly cleans up resources whether the request succeeds or fails. Timeout errors are converted to HttpClientError instances with a 408 status code, maintaining consistency with the SDK's error handling patterns.
The implementation is backward-compatible as the timeout parameter is optional, and includes comprehensive test coverage for various timeout scenarios including edge cases for fast-completing requests and configurations without timeouts.
Confidence score: 4/5
- This PR is safe to merge with minimal risk as it addresses a legitimate reliability issue with well-tested implementation
- Score reflects solid implementation using standard web APIs with proper error handling and cleanup, though the defensive User-Agent header fix suggests some edge cases may exist
- Pay close attention to the timeout error handling logic in
fetch-client.tsto ensure proper AbortError conversion
4 files reviewed, no comments
jonatascastro12
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a default conservative timeout? Maybe 30s?
Added a default of 60s to be very conservative |
## Summary Version bump to 7.69.2 ## Changes - Bump version to 7.69.2 in package.json, package-lock.json, and src/workos.ts - Update snapshot tests with new version ## Recent additions in this version - #1351
Description
fetchdoes not have a default timeout, so there is a non-zero chance of our HTTP requests to WorkOS servers hanging indefinitely. This PR introducestimeoutas an optional parameter while initializing WorkOS client to terminate the request if its taking longer thantimeoutmilliseconds.Documentation
Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.
If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.