Stuck jobs now fail fast instead of hanging
A job the runner accepts but never starts now times out with a clear error in minutes, instead of sitting forever. API key errors are clearer too, and the SDK's wait() backs off and surfaces typed errors.
If a runner accepted a job but never started executing it (a capacity problem on the execution backend), the job used to sit in a non-terminal state with no timeout. It could hang for a long time, and jobs.wait() would block until your own deadline. Now a job that has not started after its dispatch window is failed with a RUNNER_TIMEOUT error, so you get a terminal result in minutes and can retry.
Clearer auth errors
Auth errors got more honest. An API key that is rejected because it is invalid, expired, or disabled now says exactly that, instead of the generic “provide a session cookie or API key” message that read like a missing header. Per-minute request limits were also raised.
A steadier wait()
The SDK jobs.wait() is steadier on long jobs:
- Polling backs off from 2s up to 10s instead of calling the API every 2s.
- A timeout throws a typed
WaitTimeoutErrorthat names the last status, so you can tell whether the job was still queued. - Opt into
throwOnFailureto havewait()throw aJobFailedErroron a failed or cancelled job instead of returning it.
RUNNER_TIMEOUT and the auth codes are listed in error codes. Per-plan request rates are under plan limits.