Background work
Background work covers everything Barry does for you while you are not watching: an action you start and leave running, a schedule that fires overnight, a one-off run, a bag job, or a task an event triggers. Barry treats all of it the same way, and you follow all of it in one place, the Background work surface in Barry’s apps.
What a work item is
Section titled “What a work item is”A work item is one logical task: a title, what started it, a state, and eventually a result. When you start an action, a schedule fires, or a bag starts a job, Barry admits the request once and records it as one work item before it answers. From then on, the item survives restarts, lost connections, and machine changes. Retrying a submission that Barry already accepted returns the same item rather than starting a second one.
A work item may run several steps, on your machine or on another machine you linked, but you follow it as one thing. Schedules, actions, and jobs all produce work items; a schedule produces one per occurrence.
Where to find it
Section titled “Where to find it”Background work has four lists:
- Needs attention holds work that cannot continue until you decide something.
- Active holds queued, running, waiting, and stopping work.
- Scheduled holds your schedules and their next occurrences.
- History holds finished work and its results.
Each work item opens on what it is for, what started it, what is happening now, its latest progress, its result or partial output, and the controls available to you right now. Barry shows time spent running separately from time spent waiting, and never invents a percentage or an estimated finish. For attempts, machines, model endpoints, permissions, and logs, open the item’s details in the execution inspector.
States
Section titled “States”| State | What it means for you |
|---|---|
| Queued | Barry accepted it; nothing has started yet |
| Running | Work is in progress |
| Waiting | It waits on a timer, another step, or your decision; the item says which |
| Stopping | You asked it to stop; Barry has not yet confirmed that it stopped |
| Cancelled | It stopped, and Barry confirmed that |
| Completed | It finished and its result is ready |
| Failed | It ended with a known failure |
| Needs attention | Barry cannot tell what happened, so it needs you |
Controls
Section titled “Controls”Barry offers only the controls that make sense for an item in its current state, and tells you why any other control does not apply:
- Check submission looks up whether Barry received a request when you never saw the answer, for example after closing the browser. A missing response never means you should submit again.
- Continue lets held work proceed once Barry confirms that proceeding is safe.
- Retry failed step repeats a step that failed in a way Barry knows it can repeat safely.
- Run again starts a new work item, linked to the old one, with fresh effects.
- Stop ends the current item. It stays in Stopping until Barry confirms the work stopped.
- Pause future runs stops a schedule from starting new items, without touching any item already running.
Stopping and pausing differ on purpose: stop acts on this run, while pause acts on the schedule’s future occurrences.
When work needs attention
Section titled “When work needs attention”An item lands in Needs attention when Barry cannot prove what happened. A machine might have gone silent mid-step, or Barry might lack confirmation that a stopped step actually ended. Rather than guess, Barry shows what may already have happened and offers a path to check with the destination, such as looking for the message, commit, or record the step would have created. Barry never repeats an effect it cannot prove is safe to repeat, so you resolve the item with the controls it offers, such as continuing when that is safe or accepting a recovered result. Barry records your decision with the evidence behind it.
Approvals
Section titled “Approvals”Some work pauses for a person. An approval arrives as a typed decision: a prompt, the choices you can make, any input it needs, who may answer, and when it expires. Barry checks that you may answer and records your answer once, so a second click does nothing. An item shows “Waiting for your approval” only when it waits on such a decision.
Learn more
Section titled “Learn more”For how Barry keeps these promises, read Durable workflows. See also the control layer reference.