Run work in the background
Follow assistant runs and data reads, inspect progress, cancel work, and recover partial builds.
Unity can continue an accepted assistant request while you navigate to another page, minimize chat, or work in another conversation. The request runs through a background execution service, and the conversation records its progress and results.
A background run can query data and save report changes. It is still working on the same report objects that manual edits and other conversations can change.
Start and follow a run
- Submit a request in Data Chat.
- Watch the conversation's active status and tool activity.
- Navigate elsewhere if needed.
- Return to the conversation to read its completion or error state.
- Inspect the saved report result.
Build a new HTML detail page using the current model. Keep all existing
pages intact. Render and test the new page, and explain any unfinished
work when the run ends.
Closing a panel or navigating away does not itself request cancellation. If the request has not yet been accepted by the server, check its status before assuming a run exists.
Run states
| State | Meaning |
|---|---|
| Queued | The request is accepted and waiting for execution capacity. |
| Running | The assistant is inspecting, querying, authoring, or checking results. |
| Stop requested | Cancellation has been requested; an in-flight operation may still settle. |
| Completed | The run ended successfully. Review its stated outcome. |
| Failed or incomplete | A problem prevented full completion; inspect the error and saved operations. |
| Cancelled | The run stopped, potentially after some changes had already been saved. |
A long-running query or browser render can make progress appear paused. The last visible tool and current run status help explain what is happening.
Use multiple conversations
A conversation permits one active request at a time. You can draft the next message while it runs, but cannot send another active request into the same conversation.
Different conversations can submit separate jobs. Execution capacity is bounded by worker configuration, so multiple accepted jobs are not a promise of unlimited simultaneous execution.
For independent tasks, use different targets: one chat can build a new page while another investigates a query. Concurrently editing the same visual or model definition can cause conflicts.
Stop a run
Use Stop in the active conversation. A run still waiting for the assistant to start stops at once: it ends as cancelled, your message stays in the chat, and you can send the next one. A running run receives a cancellation request and Unity waits for it to settle.
Stopping doesn't reverse saved changes: a page or visual already saved remains after cancellation. To go back, restore an earlier version from Version history. A query or mutation already in flight may finish before the stop takes effect.
If the stop request fails, the composer reports the failure and allows a retry. Inspect the run state rather than assuming the browser has killed the server process.
Recover partial work
- Read the final status and activity.
- Identify saved pages, visuals, and revisions.
- Open the affected objects.
- Continue the remaining work or restore specific changes through history.
Continue the interrupted build from the current saved page. Inspect
what exists and the last errors first. Repair the missing components
and render the page again before calling it complete.
This avoids creating duplicate pages based on the mistaken assumption that a stopped run saved nothing.
Handle simultaneous edits
Supported mutations can check an expected revision or current state. If another conversation or a manual edit has changed the target, the operation can report a conflict.
The assistant should inspect the latest state and preserve intervening work. A report-wide request is a sequence of saved operations rather than one all-or-nothing transaction.
Distinguish other background activity
Visual and dataset reads
A visual refresh or SQL query has its own read lifecycle, separate from an assistant run. After the initial wait, a slow browser read continues as a polled background job. Loading can show rows read and a total when known. Those counts describe the source outputs being processed, not the number of chart marks or the size of the whole database.
Use the read's Cancel control to stop it, then refresh to start a new read. This does not undo a saved visual. The assistant can inspect and cancel read jobs through InspectReadJobs and CancelReadJob; QueryReportData reads a native visual's current data.
A read is not failed simply for taking more than a minute. Healthy reads can continue within configured resource and safety limits. By default, streaming with no progress for two minutes stops, and the safety ceiling is 15 minutes. A source still computing before its first rows and a queued read are exempt from the stall rule. A detached job with nobody polling it also stops. Completed read duration is fixed; cancellation is reported as a stopped outcome with its reason.
See Query processing for input/output limits and the HTTP reference for polling (GET /api/read-jobs/{job_id}).
File imports
CSV import processing has its own upload and validation lifecycle. Reference-file upload progress also differs from an assistant run.
Keep a CSV import dialog open during the browser transfer; later server processing can continue with it closed. See CSV imports. Use the file upload status for attachments, and wait until they are ready before submitting a message that needs them.
What completion means for HTML
The HTML build loop includes execution feedback and rendered previews. A completed save is only one step. If rendering or testing remains unresolved, the assistant should explain the gap.
Use HTML pages for verification controls and Version history to restore an earlier version.
Questions about your environment? Contact us.