Background Job

What It Models

A background job records work that continues after the initiating request. Orchestration executes it, the shared engine maintains its account, and the kind owner determines its business effect. Platform provides the common monitors, requester delivery and reconciliation of Platform jobs.

Identity and Attributes

Kind and job identity together locate a run. The submission identity identifies the intention within its kind; uniqueness prevents a second record, although an insertion race inside a caller transaction requires caller retry. Submission creates the complete queued step list and the initial history. Started and settled times remain absent until their respective events. Step transitions derive progress, and declared progress reporting can also advance it.

Relationships

Workspace lifecycle jobs create core application records and remove operational records during deletion. Licensing callers can request Security’s cache-refresh job. These are process relationships rather than mandatory foreign-key links between a licence decision and a job.

Invariants

The structured invariants distinguish database shape checks from service behavior and documented input obligations. Reporting uses transactional step, event and summary writes. Final records reject changed outcomes, while late step reports are ignored and logged. A retry retains the old job and creates a linked run.

How It Is Stored and Shared

Each kind owner keeps its root, step and event tables using the common persistence contract. Platform owns requester notice records and publishes its three monitoring views. The reader discovers compatible views across services and applies audience scope; it never writes another service’s jobs. Custom fields are absent.

Open Design Questions

Cancellation has engine support but no Platform operation or screen. Caller-transaction submission conflicts, notice delivery and failure effects after corrected reconciliation retain the limits recorded in findings.