Follow a job's status and events

Before you read a status

You need the job identifier returned when the job was admitted, and a work key that can read jobs. Reading a status changes nothing about the job.

What one reading tells you

A status reading answers four things at once.

• The job state: ADMITTED, RUNNING, AWAITING_REVIEW, PARTIAL, CANCELLING, CANCELLED, FAILED or SUCCEEDED.
• The current stage state: BLOCKED, READY, MATERIALIZING, RUNNING, VERIFYING, AGGREGATING, SUCCEEDED, PARTIAL, FAILED, SKIPPED or CANCELLED.
• The counts so far: accepted, failed, abstained and missing.
• The observation time, observed_at, and the moment that reading stops being current, valid_until.

Missing is the honest fourth number. It counts items you submitted that have not yet landed in any of the other three. It is not a fifth outcome, and it is never a silent success.

An accepted submission is not completed work

Acceptance at submission means your request passed validation and your approval was in place. It says nothing about output existing.

The same word returns at item level, with a different meaning. An accepted item has produced output that passed the workflow's checks. Neither reading closes the job on its own.

Which reading is canonical

The result bundle's result-manifest.json is written last, and it is the only complete-bundle marker. It binds every file, count, schema, release and retention decision together.

Part files appearing under data/ never mean terminal success. Until the manifest exists, every count is the current view and nothing more.

Follow a job without guessing

Read the status again rather than inferring progress from elapsed time. Every reading is stamped, so two readings tell you whether anything moved.

Your client reads one job with lithi.status. The command line can block until a batch settles with lithi batch wait. The job's event list gives you the ordered record, which is what you want when reconstructing a run after the fact.

What a healthy reading looks like

Stage states advance, and the four counts add up to the number of items you submitted. Missing falls toward zero as work settles.

When the job reaches a terminal state, the manifest exists and the counts stop moving. That pairing is your signal to download.

When a reading stops advancing

Compare two readings taken minutes apart before you act. If neither the stage nor the counts moved, read the next action carried on the response envelope. Every non-success outcome carries a safe reason and a next action, and that action is the one to take.

Do not resubmit to force progress. A resubmission under a new identity is new work and a second charge. See what a stalled job means when the next action is not clear, and how a partial job is counted when the job ends PARTIAL.