Execution state model¶
Beampipe separates its control phase from submission, scheduler, DALiuGE, and output-verification facts. Those facts can disagree, so none is allowed to stand in for the others.
Explore the control phase¶
Discover and admit
Register source identity, prepare archive metadata, compare signatures, and evaluate readiness and automation limits.
Generate manifest and graph
Pin revisions, render the manifest, apply validated patches, translate when configured, and checksum every artifact.
Persist intent, then submit
Write deterministic external identity before I/O. A lost response becomes uncertainty, not an automatic failure.
Observe independent authorities
Poll scheduler and DALiuGE state without collapsing either into the public execution status.
Verify expected outputs
Scheduler or DALiuGE completion advances the execution to output verification; it does not prove scientific success.
Record outcome and provenance
Complete, fail, or cancel only with the external identifiers, artifacts, and narrative required for later audit.
The public status is a compact operator projection: pending, running, awaiting_scheduler, not_submitted, completed, failed, retrying, or cancelled. Exact position remains in control_phase and execution_phase.
Independent external axes¶
The reducer derives the next action from all axes. A succeeded scheduler allocation with an active DALiuGE session is inconsistent and requires review; it is never promoted silently to success.
Submission uncertainty¶
Before external I/O, Beampipe persists submission intent and deterministic external identity. If SSH disconnects after sbatch, the submission axis becomes uncertain. Reconciliation searches by stable job name and checks squeue and sacct; retry stays blocked until the system can prove no scheduler job or DALiuGE session exists.
Retry gate¶
beampipe execution retry "$EXECUTION_ID" \
--reason "Translator endpoint restored after planned maintenance"
Every retry requires a reason and increments retry_count. Meaningful transitions, claims, recovery, retry, cancellation, and administrative actions append provenance or claim-history records.
Continue with the operator procedure for recovery and cancellation.