One job entry shape, published identically by every surface
Three surfaces publish a job. They publish one key set in one order, because two copies of a formatter had already drifted apart once.
The rule
- Every surface that publishes a job entry emits exactly the keys
id,label,status,priority,node_id,pipeline_id,created_at,started,completed,execution_time_us,retry_count,max_retries,error_message,input_data,output_data,metadata,timestamp, in that order: the single-job read, a run's job list and the jobs inside a run's full document. pipeline_idis a string or null; a stored value that is neither an integer nor a string is discarded rather than published under a key documented as a string, and the discard is reported, because only something outside the implementation writes a non-scalar there.execution_time_usprefers the precise duration recorded for the job and otherwise derives it from the start and completion stamps at second granularity, and is null for a job that never completed; the same value must be published for a job bynode_statusesand by the job entry, computed once, so the two payloads read side by side can never disagree numerically.
What it means
Three surfaces publish a job, and all three answer through the one key set,
in the one order — not a per-surface copy that happens to agree today.
execution_time_us is the clause worth pausing on: it is not always the
figure recorded on the job. Where none was recorded it is derived from the
start and completion stamps, at second granularity, and that derived figure
is computed once and published unchanged wherever a job's execution time
appears — so two payloads naming the same job can never disagree on it
numerically, even though neither is reading a stored precise duration.
A pipeline_id that is not a string or an integer is not published as
whatever it happens to be: it is discarded, because nothing inside the
system ever writes a pipeline_id of that shape, so its presence means
something outside the implementation wrote it.
Example
A job with no recorded precise duration, started and completed ten seconds apart:
{ "started": 1700000000, "completed": 1700000010 }10000000A job whose stored pipeline_id is a list rather than a scalar, read in the
context of a run the caller named:
["not", "a", "scalar"]"caller-pipeline"