Repository navigation
fix(workbot): keep a computer command's result when its wait is cut - #7422
Open
reachjalil wants to merge 1 commit into
Open
reachjalil wants to merge 1 commit into
reachjalil wants to merge 1 commit into
Conversation
A command ran inside the request that waited for it. When that request was cut (a runner deploy cancels a busy cell, a node is lost, or the provider's request limit is reached) nobody knew how the command had ended: bash answered "No confirmed result", and a step restarted after the cut recorded the call as interrupted, so the model had to guess whether its side effects had happened. bash now starts each command once on the computer as a detached job named after the call. The job writes its output and exit code to files under /workspace/.jobs and stops itself at the command's time limit; the request only waits for it. A wait that is cut is taken up again for what is left of the command's time, and making the job's output file is what claims a command, so it can never start twice. A step that restarts with a kept answer asks the computer for each command without a recorded result before giving up on it. A command that ended returns its real exit code and output, with its outputs added to the person's Files; one still running is waited for; one the computer never started stays an interrupted call. Calls are keyed by turn, run, step and call id, because a model may reuse its call ids. The idle pause still sees such a command as a running job. A job's .running file now names its process, so a file left behind by a command that was killed no longer keeps a computer from pausing. A command that reaches its time limit is stopped and reports what it printed so far. It runs through the existing command path from the runner, so no computer image or guest changes. Preview rendering now logs when it starts and when it ends (ids, outcome and duration), to show how often a render is lost with its runner. Signed-off-by: Jalil <reachjalil@gmail.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this about?
Commands Workbot runs on a conversation's computer (
bash) now keep running, and keep their result, when the request waiting for them is cut.What problem does it solve?
A runner deploy, a lost node or the provider's request limit could cut the wait while a command ran. The model was then told the outcome was unknown and had to guess whether a render, an install or a send had happened.
What was the situation before?
The command ran inside the request. After a cut, the step recorded "This tool call was interrupted before it returned"; a timeout answered "No confirmed result".
How is this implemented?
computer.ts:bashstarts the command once as a detached job named after the call, with its output and exit code in/workspace/.jobs. The request only waits, and a cut wait is taken up again.runner.ts: a restarted step asks the computer (pickUp, which never starts a command) before recording an interrupted call.runningJobscounts these jobs, so a computer is not paused under one.What else changed?
Release note
Workbot keeps the result of a command on its computer when the service restarts while the command runs.
Evidence
No E2E spec.
ee/packages/headless-computer/src/computer-commands.test.tsand the new case inee/apps/headless-runner/scripts/steps.test.ts— before: a command cut off with its step comes back as interrupted; after: it comes back with its exit code and output, having run once. Not run on a live computer.