sim icon indicating copy to clipboard operation
sim copied to clipboard

feat(http): add configurable timeout for API block requests

Open majiayu000 opened this issue 1 month ago • 3 comments

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

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

Fixes #2242

majiayu000 avatar Dec 22 '25 10:12 majiayu000

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

A member of the Team first needs to authorize it.

vercel[bot] avatar Dec 22 '25 10:12 vercel[bot]

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

greptile-apps[bot] avatar Dec 22 '25 11:12 greptile-apps[bot]

@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 avatar Dec 23 '25 13:12 majiayu000