Execution behavior
Understand the execution boundaries that affect your application.
Where work runs
Each job has one owner runtime node. All of its workers run there. Federation lets independent jobs use different owners, but it does not spread one job's workers across peers or migrate an active job when its owner is unavailable.
Inspect ownership and execution with:
mn node list
mn job show <job-id>
mn run show <run-id>Choose and review the runner
HostLocal uses host permissions. DockerWorker and DockerCompose use prepared container resources. OpenShell uses sandbox policies. Review mounts, environment variables, network access, and image or payload code regardless of the runner. See Security.
Waiting, retries, and deadlines
Steps wait for their declared dependencies and trigger rules. A skipped or failed predecessor can change whether downstream work runs. Retries can repeat external actions; make side-effecting workers idempotent where required.
DockerWorker buffers command output rather than streaming workflow beacons. Its task deadline remains authoritative; node-level beacon timeouts are ignored. An explicit workflow control.beacon_timeout_ms still applies when a separate producer supplies beacons. Quiet logs alone do not prove a stalled run.
Bounded child workflows hold their parent step until completion and deliver mapped results to downstream work. They execute within the parent run and are distinct from scheduled independent runs.
Inspect outcomes
Use Monitor to follow a run, download outputs, or cancel unfinished work. Completion is an execution outcome; review artifacts and warnings before using domain results. See Reliability for recovery limits and Author a blueprint for package fields.