5.3. Pre and Post Actions¶

pre_action and post_action define additional tasks that run before or after the main workflow execution.

pre_action → Tasks executed before the discovery action. These are typically used for preparation steps such as setup, or pre-processing.
post_action → Tasks executed after the main workflow completes. These are typically used for cleanup, notifications, or post-processing.

5.3.1. Configure Pre and Post Actions on a Workflow¶

pre_action and post_action can be specified during workflow creation or patched onto an existing workflow with filter_rules being the workflows primary actions.

Example¶

{
    "pre_action": [
        {
            "name": "dynamo.custom.slack_notify"
        }
    ],
    "filter_rules": [
        {
            "type": "all",
            "state": "all",
            "action": [
                {
                    "name": "dynamo.tasks.migrate",
                    "lock_level": "*lock_level"
                }
            ],
            "description": "Migrates a file off from a given path"
        }
    ],
    "post_action": [
        {
            "name": "dynamo.tasks.templated_email",
            "email_from": "ngeneahub-noreply@localhost",
            "email_to": ["root@localhost"],
        }
    ]
}

5.3.1.1. Stream Input Behaviour¶

For DAG Workflows, The stream_input flag controls how input paths are passed to actions:

true - The task receives streamed path URL references and auth_token instead of raw paths
false - The task receives the original input paths directly

When stream_input=True:

The target task must support expand_paths to correctly resolve streamed inputs

    from arcapix.dynamo.server.utils.inputs import expand_paths

    @app.task(bind=True, base=ChainedTask, name="dynamo.custom.slack_notify")
    def slack_notify(self, jobid, paths, *args, **kwargs):
        input_paths = expand_paths(paths)

If the task does not support expand_paths, it may fail or not resolve input paths correctly.

Note

The post_action supports streamed path URL references by default for SnapDiff workflows.

Example¶

{
    "name": "test_wf_pre_post",
    "label": "test wf",
    "icon_classes": ["hurricane-01"],
    "discovery": "recursive",
    "enabled": True,
    "visible": True,
    "schedule_only": False,
    "external_only": False,
    "fields": [
        {
            "name": "lock_level",
            "type": "choices",
            "label": "Locking mode",
            "choices": [{"label": "Per block (Implicit)", "value": "implicit"}],
            "default": "implicit",
        }
    ],
    "pre_action": [
        {
            "name": "dynamo.custom.slack_notify",
        }
    ],
    "post_action": [
        {
            "name": "dynamo.tasks.templated_email",
            "email_from": "ngeneahub-noreply@localhost",
            "email_to": ["root@localhost"],
        }
    ],
    "filter_rules": [
        {
            "type": "all",
            "state": "all",
            "action": [
                {
                    "name": "dynamo.tasks.migrate",
                    "lock_level": "*lock_level",
                    "stream_input": True,
                }
            ],
        }
    ],
}

5.3.2. Update or Remove Pre/Post Actions¶

To update pre_action and post_action, send a PATCH request with the updated payload.

To remove them entirely, set the fields to null.

Example¶

{
    "pre_action": null,
    "post_action": null
}

5.3.3. Configure Pre and Post Actions at Runtime¶

To configure pre_action and post_action at runtime, include them in the payload when calling the API /api/file/workflow. These will override any pre/post actions already defined on the workflow.

Example¶

{
    "discovery": "recursive",
    "paths": ["/mmfs1/data/aws/"],
    "site": "siteA",
    "workflow": "test_wf_pre_post",
    "pre_action": [
        {
            "name": "dynamo.custom.slack_notify",
            "hook": "https://hooks.slack.com/services/",
            "message": "Job {jobid} completed on site {site} with paths {paths}"
        }
    ],
    "post_action": [
        {
            "name": "dynamo.tasks.templated_email",
            "email_from": "ngeneahub-noreply@localhost",
            "email_to": ["root@localhost"]
        }
    ]
}

5.3.3.1. Disable Runtime Pre/Post Actions¶

To disable runtime pre_action and post_action, pass null for those fields.

Example¶

{
    "discovery": "recursive",
    "paths": ["/mmfs1/data/aws/"],
    "site": "site1",
    "workflow": "test_wf_pre_post",
    "pre_action": null,
    "post_action": null
}

5.3.4. Runtime Fields¶

pre_action and post_action support runtime field references.

For example, if:

"site": "*destinationsite"

is specified, the action will run on the destinationsite value provided at runtime.

Example¶

{
    "fields": [
        {
            "name": "destinationsite",
            "type": "enum[site]",
            "label": "Destination Site"
        }
    ],
    "pre_action": [
        {
            "name": "dynamo.tasks.migrate",
            "site": "*destinationsite"
        }
    ]
}

5.3.5. Configure Pre and Post Actions on a Schedule¶

To configure pre_action and post_action for a schedule, include them in the SubscribedWorkflow api /api/schedules/{id}/workflows/

Note

Any pre_action or post_action already defined on the workflow itself will be ignored for schedules. The actions configured on the subscribed_workflow take precedence.

Example¶

{
    "site": "siteA",
    "workflow": "site_sync",
    "fields": {
        "destinationsite": "siteB",
        "destinationqueue": "default",
        "sync_preference": "newest"
    },
    "queue": "default",
    "pre_action": [
        {
            "name": "dynamo.custom.slack_notify",
            "hook": "https://hooks.slack.com/services/",
            "message": "Job {jobid} completed on site {site} with paths {paths}"
        }
    ],
    "post_action": [
        {
            "name": "dynamo.tasks.templated_email",
            "email_from": "ngeneahub-noreply@localhost",
            "email_to": ["root@localhost"]
        }
    ]
}

5.3.6. Schedule Behaviour¶

5.3.6.1. SnapDiff Workflows¶

For SnapDiff workflows, the pre_action and post_action of the first SubscribedWorkflow are respected when the schedule is triggered.

5.3.6.2. DAG Workflows¶

For DAG workflows, the pre_action and post_action are executed for each workflow individually.

5.3.6.3. Bidirectional Sync Schedules¶

For bidirectional sync schedules, the post_action is triggered only after the second rotate task completes.