start() and build() with wait_for_finish above 30 s time out and retry the POST, starting a duplicate run #1132

ActorClient.start() and TaskClient.start() send waitForFinish and keep the plain 'medium' request timeout of 30 s (actor.py#L237-L327, task.py#L215-L295, _consts.py#L14). ActorClient.build() does the same (actor.py#L431-L477), and default_build() uses 'short' (5 s) for a GET that can be held up to 60 s (actor.py#L493-L529). The async twins match.

The API holds the response for up to wait_for_finish seconds (the docstring allows 60). When that exceeds the request timeout, the first attempt times out while the API is still holding it. Timeouts are retryable transport errors, so the client sends the POST again with a doubled timeout (_base.py#L258-L295). The first run (or build) already exists, so actor.start(wait_for_finish=60) on an Actor that runs for more than 30 s starts two runs and returns the second. For default_build(wait_for_finish=60), the GET is repeated at 5, 10, 20 and 40 s before one attempt outlasts the hold.

The JS client adds the hold to the tier timeout when the caller does not pass one: timeoutForWaitForFinish (resource_client.ts#L35-L47), used by start(), build(), defaultBuild() and task start() (actor.ts#L253, #L429, #L474, task.ts#L221).

Expected behavior

When wait_for_finish is set and the caller passes a tier timeout, the request timeout is min(wait_for_finish, 60) plus the tier value. An explicit timedelta timeout is used as given. Applies to ActorClient.start(), build(), default_build() and TaskClient.start(), sync and async.

✍️ Drafted by Claude Code