Stored runs in solution drafts¶

Overview¶

A solution draft project can have its own stored runs, schedules and notifiers. They work the same way as in the execution project, with three differences:

Draft stored runs, notifiers and monitorables belong to the draft only. Draft runs never update the execution project's monitorables, and the execution project's runs never update the draft's.
A draft stored run can sync data from the execution project into the draft before its workgraph starts (the pre_run setting). Execution stored runs reject pre_run.
Publishing a draft never copies stored runs or notifiers in either direction. The execution project keeps its own.

Stored runs and notifiers are created and edited with toolbelt. The console lists them on the draft project's Stored Runs and Notifiers tabs.

Prerequisites¶

Toolbelt configured for the environment, with the context set to the draft project: au3 ctx set --id <draft project id>.
The solution installation on a solution version that supports draft stored runs (v1.8.21 or later). Older versions run draft stored runs but skip the pre-run sync without an error.

Create a stored run¶

au3 sln inst wg stored-run create --name nightly

Note the sistrun-... id it returns. The stored run selects no nodes yet. Configure it with stored-run update and a spec file:

au3 sln inst wg stored-run update --spec stored_run.yaml

Every top-level field in the spec replaces that field on the stored run. Fields left out keep their current value. To change one part of schedule or pre_run, pass the whole object.

Example spec¶

Runs the processing and delivery phases every night at 2:00 AM Eastern, skipping one delivery transfer. It syncs one table from the execution project first and alerts a notifier on errors and failures:

id: sistrun-<id>
name: nightly
node_filter:
  and:
    - field: phase
      op: in
      val:
        - processing
        - processed_model
        - delivery
    - field: id
      note: exclude the remote warehouse delivery
      op: nin
      val:
        - sideltrf-<id>
schedule:
  enabled: true
  cadence:
    type: cron
    minute: '00'
    hour: '2'
    day_of_month: '*'
    month: '*'
    day_of_week: '*'
    timezone: America/New_York
notification:
  inflight_error:
    enabled: true
    notifiers:
      - sinot-<id>
    priority_default: P3
    recurring: false
  run_failed:
    enabled: true
    notifiers:
      - sinot-<id>
    priority: P2
pre_run:
  sync_draft_data:
    enabled: true
    data_clone_mode: partial
    data_clone_containers:
      - warehouse: whs-<draft warehouse id>
        entities:
          - tbl_<id>

Field	Notes
`node_filter`	Workgraph nodes to run: a filter on node `id`, `name`, `phase` or `description`, usually an `and` list. `note` documents a clause and is ignored. `path_filter` is also supported and is applied first.
`schedule.cadence`	Cron fields as quoted strings (`'*'`, `'0'`), in the same order as the five fields of a cron expression; crontab.guru builds one. `timezone` is a tz database name and defaults to `UTC`.
`notification`	Same kinds as execution. `run_failed` and `run_succeeded` take `priority`; `inflight_warning` and `inflight_error` take `priority_default` and `recurring`. `node_selection_succeeded` supports webhook notifiers only.
`pre_run`	Draft only. See Pre-run data sync.

Pre-run data sync¶

With pre_run.sync_draft_data.enabled set, every run of the stored run first starts a Sync Draft Data task (solution-installation:sync-draft-data) in the draft. The workflow starts only after that task succeeds.

`data_clone_mode`	What is synced
`all` (default)	All of the draft's data from the execution project. Slow on large installations.
`partial`	Only `data_clone_containers`. Each entry is a draft warehouse id, with optional `entities` to limit it to specific tables. Required in this mode.

Behavior:

If the sync fails or is canceled, the workflow does not start and the run fails. The stored run's run_failed notifiers are alerted with "Stored Run '<name>' failed before workflow launch".
When a failed run is recovered, the sync runs again unless the earlier attempt had already started its workflow.
Scheduled and manual runs both sync.

Notifiers¶

au3 sln inst wg notifier create --name nightly-alerts --method ops-genie
au3 sln inst wg notifier update --spec notifier.yaml

id: sinot-<id>
name: nightly-alerts
enabled: true
api_key: <key>
team_name: <team>

Notifiers are created disabled. Set enabled: true before a stored run can use them. Methods are ops-genie, brevo and webhook, as in the execution project.

OpsGenie alerts from a draft are titled with a [DRAFT] prefix, for example [DRAFT] [<org> - <draft project>] Stored Run 'nightly' failed before workflow launch: ....

Run, monitor and remove¶

Task	Command
Run a stored run now	`au3 sln inst wg run --stored-run sistrun-<id>`
List recent runs	`au3 sln inst wg submission list --limit 5`
View a stored run	`au3 sln inst wg stored-run view --id sistrun-<id>`
Draft monitorables	`au3 sln inst monitorable list --limit 20`
Turn a schedule off	`stored-run update` with `schedule.enabled: false` (pass the whole `schedule`)
Delete a stored run	`au3 sln inst wg stored-run delete --id sistrun-<id>`

Scheduled runs show scheduled: true in submission list. A draft's monitorables exist only while the draft has at least one stored run. Deleting the last stored run removes them.

Draft and execution runs can run at the same time, including when they select the same nodes.

Errors¶

Message	Cause
`pre_run.sync_draft_data: is only supported on draft installations`	`pre_run` was set on an execution stored run.
`Must specify data containers to clone when mode is "partial"`	`data_clone_mode` is `partial` without `data_clone_containers`.
`Duplicate warehouse containers detected: <ids>`	The same warehouse is listed twice in `data_clone_containers`.
`Stored run "<id>" not found`	Wrong id, or the context is set to the other project of the pair.