Jobs and generation history

Studio jobs track media requests as they move through validation, queueing, processing, and terminal outcomes. The current jobs foundation is useful for inspecting progress and errors, but its persistence is not production durable. The generation API describes local private-beta storage, while the Jobs UI describes an in-memory store; keep that conflict visible.

Job lifecycle

A job is created after a media request passes the applicable validation and safety checks. Accepted generation returns HTTP 202 because processing can continue after the initial response.

The workbench can report client phases such as validating, estimating, generating, finalizing, and completed. The underlying job states are broader and can include prerequisites or terminal failures.

A media job is distinct from a Workflow Agent preview run or an agent run. It records a Studio generation request, its processing state, results, and usage estimates.

Queue states

Do not convert these states into public timing guarantees. Polling behavior and internal limits are implementation details rather than service commitments.

History

The Studio Jobs route displays current job records and can expose progress, result information, and status. History is constrained by the current store.

The generation API reports storage: "local private-beta storage" and isProductionDurable: false. The UI describes its job store as in-memory and non-durable. Both sources agree that production durability is absent, but they differ on the exact temporary mechanism.

Do not claim that history survives every restart, deployment, or environment change. A completed item can disappear when the underlying non-durable store is reset. Retain important prompts, references, and outputs elsewhere through an approved enabled process.

Failures

A job can fail because of request validation, missing models, provider setup, provider errors, safety decisions, routing, unavailable source media, or an internal processing problem.

Read the returned error and current state before retrying. A setup-required result will not improve through repeated submission. A blocked safety outcome must not be bypassed. An awaiting-upload job needs the required reference media rather than another identical request.

Provider errors may lead to fallback or mock behavior depending on the specific route and configuration. Label the result using the state actually returned; do not report a mock or fallback asset as a live provider output.

Retry behavior

The jobs API supports retry behavior where the current job and route allow it. This is not a universal retry promise. Terminal state, error category, provider readiness, safety, and required inputs determine whether another attempt is appropriate.

Retry a transient processing failure only through the supported jobs control or API behavior. Do not retry canceled, expired, policy-blocked, safety-blocked, or setup-required work as though all failures were temporary.

A retry can create or update another current job record, but the source bundle does not guarantee idempotency, attempt counts, backoff, or long-term linkage between attempts. Estimated usage may change with another attempt.

Troubleshooting

If a job remains active, inspect progress before resubmitting. If the workbench and Jobs page disagree, use the job API or current record as the more specific source and retain a cross-page consistency note.

For a missing historical record, consider the non-durable storage posture before assuming deletion. For a completed job with no asset, compare the result reference and asset store; the output may not have been persisted in the same way as the job.

Include the job identifier, state, modality, provider status, and returned error when requesting product support. Do not include credentials or sensitive source media. Estimated credits and settlement labels are operational estimates, not invoices.

Active-state interpretation

Queued, planning, running, and processing are all active but describe different work. Queued indicates waiting. Planning can include route or provider preparation. Running and processing indicate that work has started, but the source does not define a public distinction suitable for timing guarantees. Use the exact state returned.

Awaiting upload and awaiting approval are not ordinary queue delays. They require a missing input or supported decision before work can continue.

Terminal outcomes

Completed, failed, canceled, and expired should not be retried identically. Completed calls for result review. Failed calls for error analysis. Canceled records an intentional stop where supported. Expired means the current store no longer treats the job as active.

A terminal state does not by itself explain persistence. A completed job can still lose its result when the non-production store resets.

Usage and settlement labels

The media foundation can record estimated usage and settlement-related labels. Treat them as operational estimates. They do not establish a final invoice, fixed credit price, or billing commitment. Another attempt may change the estimate.

Correlating UI and API

If the workbench history shows a different state from the Jobs page, compare the job identifier and most recent API record. The mismatch may reflect stale client state rather than a second job. Do not merge two records simply because prompts are similar.

Retry decision

Retry only after the cause is understood. A transient provider failure may be eligible; missing setup, unsupported modality, absent reference media, safety block, or disabled capability is not repaired by another attempt. The jobs API behavior must govern the action, and universal retry counts or backoff remain undocumented.

Job creation boundary

A job is created only after the generation route accepts the request. Client-side validating or estimating before that point should not be treated as a stored job. If the API rejects the request, troubleshoot the returned error rather than looking for a history entry.

Awaiting states

awaiting upload indicates that required source media is missing or not available to the job. awaiting approval indicates a supported gate or consent requirement. These states need an action, not passive waiting. The exact control must come from the active workbench.

Canceled and expired records

A canceled job should not be described as failed unless the current source uses that error. An expired job is no longer active in the current store, but no fixed expiration interval is verified. Avoid promising restoration or retention.

Result and asset correlation

The job result can point to an asset, while the asset surface stores or displays the media reference. When one side is missing, retain the job identifier and investigate the store boundary. Do not create a duplicate generation immediately if the provider may already have completed work.

Retry cost and safety

Another attempt can create additional estimated usage and may repeat provider processing. Confirm that the cause is retryable and that safety or approval does not prohibit the action. No universal attempt limit or idempotency guarantee is verified.

History as an operations tool

Use the Jobs page for current private-beta operations: state, progress, result, and error inspection. Do not describe it as an enterprise audit log or long-term media archive. Those claims require durable persistence and retention evidence.

Stale client state

A workbench can display an earlier phase after the job record has advanced. Use the job identifier to compare views and refresh before assuming processing is stuck. Do not create a second job solely because the local stage did not update.

Partial result handling

The current source bundle does not define a universal partial-success state. If a job has an asset reference and an error, preserve both and request implementation review rather than labeling it completed or failed by assumption.

Non-durable history and support

When a record disappears, provide the prompt time, app route, modality, and any retained identifier to support. Do not claim that the system deleted the job or that it can recover it. The temporary store may simply have reset.

Job privacy

Job metadata can reveal prompts, source references, model choices, or project context. Share only the fields needed for diagnosis and follow Privacy and Terms. Jobs implementation evidence does not verify a fixed retention period or access-control model for history.

Expired versus missing

An expired record was represented as a terminal state; a missing record may never have been stored or may have been lost with the temporary store. Do not use the terms interchangeably.

Operational completion

A job investigation is complete when the state, error or result, provider status, and asset reference are understood. If the store conflict affects the conclusion, retain the persistence review flag rather than choosing one description.

State labels are authoritative

Use the exact current job state rather than replacing it with a friendlier summary that could hide whether work is active, blocked, or terminal.