Skip to content

ActorClient.call and TaskClient.call apply timeout only to the start request #1171

Open

Description

@vdusek

ActorClient.call(timeout=...) passes timeout to start (actor.py#L394-L407) and then calls run_client.wait_for_finish(wait_duration=wait_duration) without it (#L416-L417, #L428-L429). wait_for_finish defaults to timeout='no_timeout' (run.py#L140-L145), so every poll runs without a timeout. TaskClient.call does the same (task.py#L349-L369), and so do both async variants (actor.py#L954-L990, task.py#L757-L776). The docstring says only "Timeout for the API HTTP request".

A caller who passes timeout=timedelta(seconds=90) to guard against a stuck connection gets that guard on the start request only. If a poll connection hangs (a half-open TCP connection, a proxy that never answers), call() hangs with it. The server holds each poll for at most about 60 seconds, so a 90 s timeout would never cut off a healthy poll.

The JS client passes timeoutSecs to both start and waitForFinish (actor.ts#L313-L331, task.ts#L256-L267) and documents it as "Timeout for each API request, the start and every poll alike".

Expected behavior

call() forwards timeout to wait_for_finish in all four variants, and the docstring says it applies to the start request and to every poll.

✍️ Drafted by Claude Code

Activity

  1. added
    bugSomething isn't working.
    t-toolingIssues with this label are in the ownership of the tooling team.
    on Oct 30, 2026
  2. added theissue type on Oct 30, 2026
  3. removed
    bugSomething isn't working.
    on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    t-toolingIssues with this label are in the ownership of the tooling team.

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions