Jobs, progress & errors

Where a running job reports itself

Once a job is created, the addon asks the server what it is doing every three seconds, starting two seconds after the job is accepted. Whatever comes back is written into the cloud log in the pipeline's own words: each step the cloud finishes prints one line, and a step that holds the same label for more than twenty seconds prints a patience line every twenty seconds after that, so the log keeps moving and no long step reads as stuck.

The composer conversation in Design → Theme is the first place those lines land. It shows your prompt, then the cloud's step feed beneath it as the run progresses.

Beside the composer's icon row is a small ring that appears only while a job exists. It is blue while the job runs, green when it has finished and red when it failed, and it fills as the job advances. Clicking it opens the CLOUD ACTIVITY popup: the step ladder on top, the full cloud log beneath, both re-read live.

The same ring sits at the top right of the iCity Logs editor and opens the same popup. It is the only trace of the cloud in that editor: cloud lines are deliberately kept out of the Logs editor's own stream, which carries engine and addon events. The composer thread and the Cloud Activity popup are the two places a cloud line is readable.

The steps a job moves through

Every cloud job is drawn on the same eight-step ladder, in this order. Not every job visits every step — Review only happens when the cloud has something to ask you, and Guides only on a theme — and a job whose guides you re-roll finishes where it stands and continues in a child job that starts the ladder again.

The percentage under the ladder is derived from where the job sits on these eight steps, not from a progress figure the server reports. A long step therefore holds the same percentage for as long as it runs; the log lines beneath it are the live part.

Three states end a job rather than advance it.

• —Complete — the ring fills green and the closing log line reads Job 3f9a21c4 complete, carrying the credits the cloud actually charged.
• —Failed — the ring turns red. The closing line carries the failure and, if the cloud charged for work it had already done, those credits with it.
• —Cancelled — the ring fills and reads Job cancelled. A cancelled job is finished, not broken.

What is kept about a job

The addon keeps one record per job you submitted this session. It is what the step ladder, the ring, the asset browser's “generating” card state and the Chats history all read from.

The Chats popup lists these records as your prompt history, each in a four-line box with a coloured kind pill and its own Copy and Insert buttons, so you can reuse an earlier prompt.

Stopping a job

While a job is running, the composer's send arrow becomes a red stop square. Pressing it cancels the job on the server: the pipeline stops and the job row is written as cancelled. The call is idempotent, so pressing it on a job the server has already closed comes back as Job was <whatever the server says it already is>. rather than an error. A record with no cloud job id behind it at all answers Stopped tracking — this record has no cloud job id.

The local record is only marked Cancelled if the server agreed. Read the line the cancel prints into the cloud log before you assume the run is over.

• —Job cancelled — the pipeline stopped. Nothing further is billed.
• —Cancel refused or Cancel failed — the job is still running and still spending. The record stays on the ladder rather than going quiet over a live run.
• —Marked cancelled, but the pipeline did NOT stop — check the job in the console. The job row was cancelled but the execution refused to stop. This is the one case where the bill keeps running after a cancel.

A job parked on Review is the moment people most want out, because the two buttons in front of them both spend money: Approve continues into asset generation and Regenerate buys another set of guides. Closing the THEME GUIDES popup is not a cancel — its close button is Close (decide later) and the job waits on the cloud indefinitely. Cancel from the composer's stop button instead.

When a job is refused or fails

A submit the server refuses never becomes a running job. The addon maps the response into a headline, prints the status code with it into the cloud log, and the job record goes straight to Failed.

The 402 case is the one worth recognising on sight. The message reads “This action needs more credits than you have.” and, when the server sends your usage figure, it appends “Your credit usage is at 96%.” No credits were charged. The way out is to free up credits or move up a plan and resubmit — see credits and plans.

Today only the code and the headline are shown. The addon also records what happened, what it cost and what to do next on the job record, but nothing in the interface draws those three lines yet, so the log line is all you get.

An accepted submit is charged a one-credit analysis fee at creation; that is the credit riding the Job 3f9a21c4 created line. After that the meter measures real work and charges when the run ends, and there is no credit gate on the server: a run that costs more than your balance still completes and leaves the balance negative rather than stopping halfway. A full theme is roughly 220–275 credits and about twenty minutes; the composer's own on-screen estimate, ~219 credits · ~18 min, is a hard-coded measurement rather than a live quote, and it runs low against a measured spread of 272–274.

A job that finishes while Blender is closed

There is a partial recovery, and its limit matters. The cloud streams the dressed city's files into your project folder during the run, so if the job got far enough the outputs may already be on disk. Dress City from Outputs applies whatever is there.

1. Open the project the job belonged to, so the outputs it wrote belong to the active project.
2. Press F3 in the 3D viewport to open Blender's search and type Dress City from Outputs. The operator is on no panel — search is the only way to it.
3. Run it. It imports outputs.usd and outputs.csv and links assets.json onto the city, through the same entry point the automatic path uses. It is safe to press repeatedly: a re-run clears what the previous one created rather than stacking on top.

The limit: it reads the project folder and nothing else. It cannot re-download assets or outputs from the cloud, so a job whose results never reached your disk cannot be recovered from the interface at all. If the entry is greyed out, the project has no outputs.csv and there is nothing for it to apply. And it needs outputs.csv and assets.json to actually dress anything — assets.json is written only when the job completes, so a run cut off before that can bring the geometry in and still leave it undressed.

For what a completed dress puts in your scene, see after a dress. For which work is paid at all, see what runs in the cloud.