Skip to content

Conversation

@majiayu000
Copy link
Contributor

Summary

  • Add configurable timeout parameter to HTTP request tool
  • Add timeout field to API block UI (default: 120000ms, max: 600000ms)
  • Improved timeout error message with actionable guidance

Test plan

  • All HTTP request tests pass (23 tests)
  • Manual testing with slow API endpoints

Fixes #2242

icecrasher321 and others added 8 commits December 18, 2025 16:23
…dioai#2481)

The realtime service network policy was missing the custom egress rules section
that allows configuration of additional egress rules via values.yaml. This caused
the realtime pods to be unable to connect to external databases (e.g., PostgreSQL
on port 5432) when using external database configurations.

The app network policy already had this section, but the realtime network policy
was missing it, creating an inconsistency and preventing the realtime service
from accessing external databases configured via networkPolicy.egress values.

This fix adds the same custom egress rules template section to the realtime
network policy, matching the app network policy behavior and allowing users to
configure database connectivity via values.yaml.
Adds timeout parameter to HTTP request tool and API block:
- Default timeout: 120000ms (2 minutes)
- Max timeout: 600000ms (10 minutes)
- User-friendly error message on timeout

This allows users to configure longer timeouts for slow API endpoints.

Fixes simstudioai#2242
@vercel
Copy link

vercel bot commented Dec 22, 2025

@majiayu000 is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Dec 22, 2025

Greptile Summary

This PR adds configurable timeout support to the API Block, addressing issue #2242 where workflows were timing out on slow API endpoints. The implementation includes:

  • UI Configuration: Added timeout field to API block with default 120000ms (2 min) and max 600000ms (10 min)
  • Timeout Logic: Implemented AbortSignal.timeout() in handleInternalRequest() with proper parsing for both number and string inputs
  • Error Handling: Enhanced timeout errors with actionable guidance ("Consider increasing the timeout value")
  • Type Safety: Added timeout?: number to RequestParams interface
  • Infrastructure: Added custom egress rules support to network policy (unrelated to timeout feature)

The timeout flows through the execution chain: API Block UI → executeTool()handleInternalRequest()fetch() with AbortSignal. The implementation correctly handles both internal routes and proxy requests, with the timeout parameter properly passed through the entire call chain.

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk
  • The implementation is clean, well-structured, and follows best practices. The timeout logic properly validates inputs, enforces maximums, handles errors gracefully, and provides user-friendly error messages. All HTTP request tests pass (23 tests). The change is backward compatible with a sensible default, and the timeout parameter flows correctly through the execution chain.
  • No files require special attention

Important Files Changed

Filename Overview
apps/sim/blocks/blocks/api.ts Added timeout UI field (default: 120000ms, max: 600000ms) and timeout input parameter to API block configuration
apps/sim/tools/http/request.ts Added timeout parameter definition with default 120000ms and max 600000ms to HTTP request tool config
apps/sim/tools/index.ts Implemented timeout logic with AbortSignal, proper error handling, and user-friendly timeout messages

Sequence Diagram

sequenceDiagram
    participant User
    participant APIBlock as API Block UI
    participant ExecuteTool as executeTool()
    participant HandleInternal as handleInternalRequest()
    participant Fetch as fetch() with AbortSignal
    participant ExternalAPI as External API

    User->>APIBlock: Configure API call with timeout (e.g., 300000ms)
    APIBlock->>ExecuteTool: Execute with params {url, method, headers, body, timeout}
    ExecuteTool->>HandleInternal: Forward params with timeout
    HandleInternal->>HandleInternal: Validate & parse timeout<br/>(default: 120000ms, max: 600000ms)
    HandleInternal->>Fetch: Create AbortSignal.timeout(timeoutMs)
    Fetch->>ExternalAPI: HTTP Request with timeout signal
    
    alt Request completes before timeout
        ExternalAPI-->>Fetch: Response
        Fetch-->>HandleInternal: Success response
        HandleInternal-->>ExecuteTool: ToolResponse with data
        ExecuteTool-->>User: Success with API response
    else Request times out
        Fetch-->>HandleInternal: TimeoutError
        HandleInternal-->>HandleInternal: Catch error, check error.name === 'TimeoutError'
        HandleInternal-->>ExecuteTool: Error: "Request timed out after Xms. Consider increasing the timeout value."
        ExecuteTool-->>User: User-friendly timeout error message
    end
Loading

The previous implementation only added timeout to handleInternalRequest,
but external API requests go through handleProxyRequest which was missing
the timeout logic. This caused the proxy fetch to use default timeout
instead of the user-configured value.

- Add timeout parsing logic to handleProxyRequest
- Add AbortSignal.timeout to proxy fetch call
- Add user-friendly timeout error message

Fixes the issue reported by @ARNOLDAJEE where 600000ms timeout setting
was not taking effect for external API requests.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@majiayu000
Copy link
Contributor Author

@ARNOLDAJEE I've identified and fixed the issue!

Root Cause: The timeout was only implemented in handleInternalRequest, but external API requests go through handleProxyRequest which was missing the timeout logic. This caused the proxy fetch to use the default timeout instead of your configured 600000ms value.

Fix: Added the same timeout logic to handleProxyRequest:

  • Parse params.timeout parameter (supports both number and string)
  • Add AbortSignal.timeout(timeoutMs) to the proxy fetch call
  • Add user-friendly timeout error message

The fix has been pushed. Could you please test again after this PR is merged?

majiayu000 and others added 2 commits December 23, 2025 21:28
Add comprehensive unit tests to verify:
- Numeric timeout parsing
- String timeout parsing
- MAX_TIMEOUT_MS cap (600000ms)
- DEFAULT_TIMEOUT_MS fallback (120000ms)
- Invalid value handling
- AbortSignal.timeout integration
- Timeout error identification

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
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.

4 participants