Run a project workflow

Runs every ready node that has no hold. Execution proceeds in topological waves: each wave contains nodes whose upstream inputs are already available. Nodes within a wave are mutually independent. With parallel = "auto" (the default) and active mirai::daemons set, a wave is dispatched concurrently; otherwise it runs sequentially in topological order. Either way the protocol holds and the pause flag are evaluated at wave boundaries, so a hold discovered from a fresh summary in one wave takes effect before the next wave is dispatched.

Usage

bg_run(
  project,
  targets = NULL,
  parallel = c("auto", "never", "always"),
  rerun = character()
)

Arguments

project

A bg_handle.

targets

Optional character vector of target node IDs.

parallel

One of "auto", "never", "always". "auto" (default) dispatches waves in parallel when mirai daemons are active, otherwise falls back to sequential execution. "never" always runs sequentially. "always" requires mirai and active daemons, erroring if unavailable.

rerun

Optional character vector of node IDs to execute even when their result is cached. Use it to record provenance for results computed before provenance existed, or to bind a node to its own output when it reuses another node's cached artifact. The listed nodes form a pending set for this call: a pending node's cached output does not count as available, so its descendants wait until it has executed, and it leaves the set once its execution is finalized. Gates and workflow holds apply as usual; a held node stays unexecuted and is reported in metadata$rerun_pending of the returned handle. Descendants are not re-executed implicitly, because their fingerprints are unchanged; list them too to refresh them. With targets, the listed nodes are added to the targets.

Value

A bg_run_handle list.

Details

Each successful execution records its provenance in its final job record (see bg_jobs() and bg_node_pad()): the inputs passed to the executor, what the executor consumed, the settings it actually used, the environment that ran it, and a P/A/D snapshot when the node kind declares one. Summaries written by an execution carry its job_id.