FlowDrop Workflow Specification 1.0-draft

A run's jobs are the ones the run itself names

Every surface that publishes jobs answers from the run's own list of them, so the full document, the job list and the job status summary can never disagree about which jobs a run has.

The rule

Normative: this is the rule
  1. A run holds the reference to each job as that job is created, and that reference is the only source from which jobs are resolved: the full run document, the run's job list and the run's job status summary must all publish the same set.
  2. A job must not be attributed to a run by scanning jobs for a stamp, because nothing is required to write one.
  3. Where a single job is read outside the context of a run, its reported pipeline_id is the most recent run that references it among those the caller may view; candidates are ordered so that two identical requests answer identically, and a candidate the caller may not view is walked past rather than returned as null, since seeing a job is not authority to learn which run it belonged to.
  4. The walk is bounded, and null means no candidate is viewable.
  5. More than one referencing run is a broken invariant and is reported, naming the job and every candidate, rather than resolved by an arbitrary pick.
  6. Each run-scoped surface additionally filters its jobs by per-job view authority: authority over a run never implies authority over its jobs.
Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · PIPE-5 · changed in spec 1.0