Run work in the background

Use this when you want a task to keep going after you walk away, and to find its result later in one place. Barry records every piece of background work, whether you start it, a schedule fires it, or a bag starts a job, as one work item in the Background work view. The commands act as the bonanza identity from Build a Barry.

Before you begin

You have an action that can run on its own, with context: none in its action.yaml. Using actions shows how to write one.
You know the inputs the action takes. The examples use nightly-triage, the action from Run work while you sleep.

Start the work

Start the action from the command line:

bonanza action run nightly-triage --input team=platform

Or open Background work, choose the task by name, and fill in its inputs. Barry picks the identity and the machine from context and explains the choice before it starts. A schedule starts work the same way, once per occurrence.

Barry admits the request once and records it as a work item before it answers. From then on the item survives restarts, lost connections, and changes of machine.

Follow it

Open Background work. A new item appears under Active, in one of these states:

Queued: Barry accepted it, and nothing has started yet.
Running: the work is in progress.
Waiting: it waits on a timer, another step, or a decision, and says which.
Stopping: you asked it to stop, and Barry has not yet confirmed that it stopped.

Open the item to see what it is for, what started it, what is happening now, its latest progress, and the controls you can use right now. Barry shows time spent running apart from time spent waiting. It never shows a percentage or an estimated finish, because it cannot know them. For attempts, the machine, the model endpoint, permissions, and logs, open the item’s details in the execution inspector.

Lose the response safely

When you start work and never see the answer, for example because you closed the browser, use Check submission on the task. Barry looks up whether it received the request. Don’t start the task again: a missing response never means Barry missed the request, and starting it again is a new request that makes a second item.

Stop it or pause its schedule

Stop ends this item. It stays in Stopping until Barry confirms the work stopped, then moves to Cancelled. Barry does not promise to undo effects the work already had.
Pause future runs stops a schedule from starting new items. It leaves an item that is already running alone.

Run it again

Retry failed step repeats a step that failed in a way Barry knows it can repeat safely. Barry offers it only then.
Run again starts a new item with fresh effects, linked to the old one.

Verify

When the work finishes, the item moves from Active to History as Completed, and its detail shows the result. Barry notifies you for a result you asked for, a decision it needs, or a failure that persists, and it keeps routine successful work quiet.

If it fails

The item shows Failed. Read the reason on the item. Use Retry failed step when Barry offers it, or fix the cause and use Run again.
The item lands in Needs attention. Barry cannot prove what happened, so it needs you. Follow Resolve approvals and decisions.
The item stays Queued. Check that Barry’s services run; see See what is running.