Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@nave91
Copy link
Contributor

@nave91 nave91 commented Aug 27, 2025

Description

fetch does not have a default timeout, so there is a non-zero chance of our HTTP requests to WorkOS servers hanging indefinitely. This PR introduces timeout as an optional parameter while initializing WorkOS client to terminate the request if its taking longer than timeout milliseconds.

Documentation

Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.

[ ] Yes

If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.

@nave91 nave91 requested a review from a team as a code owner August 27, 2025 14:09
@nave91 nave91 requested a review from jonatascastro12 August 27, 2025 14:09
Copy link
Contributor

@greptile-apps greptile-apps bot left a 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.ts to ensure proper AbortError conversion

4 files reviewed, no comments

Edit Code Review Bot Settings | Greptile

Copy link
Contributor

@jonatascastro12 jonatascastro12 left a 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?

@nave91
Copy link
Contributor Author

nave91 commented Aug 29, 2025

Should we have a default conservative timeout? Maybe 30s?

Added a default of 60s to be very conservative

@nave91 nave91 merged commit 85f379b into main Sep 3, 2025
5 checks passed
@nave91 nave91 deleted the feature/add-timeout branch September 3, 2025 13:46
@nave91 nave91 mentioned this pull request Sep 3, 2025
nave91 added a commit that referenced this pull request Sep 3, 2025
## 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants