v0.35.12

Changes to note

• A task that is still waiting when the hard time limit passes (queued for a free slot, or restoring a workspace that hangs) now ends failed with "reason": "timeout" in its response record as soon as it is settled, so a client polling GET /v1/responses/{id} sees it end. Before, its session said failed while the response record stayed in_progress.
• Once settled, such a task never starts its agent. Before, when the wait ended it ran anyway, and finished as completed after it had been settled as timed out.

Checked on the test VM with the limits scaled down (one task at a time, a 90-second limit, three tasks queued behind one slot). On 0.35.11 the third task's record stayed in_progress after its session failed at 99 s, then the task ran and completed at 153 s. On this release its record ended failed with the timeout error at 100 s, the task stayed in the list as failed, and nothing ran after.

Known items

• The hard limit was checked live only on scaled time (a 90-second limit). The production limit, the runner's limit plus a 30-minute margin, runs the same code and is covered by tests, but no task has run into it live.

Found while porting 0.35.11 to the hosted service.

What's Changed

• gateway: a turn the sweep settles at the cap settles its response record too, and never starts the agent afterwards by @github-actions[bot] in #539

Full Changelog: v0.35.11...v0.35.12