Responding to action results

🧑‍💻 Get Mechanic!🧑‍🔧 Task library 🗳 Task requests 🦾 Mechanic.dev
Search…
In writing a Mechanic task, it may be necessary to do more than a single round of work. The task may need to act based on the content of a previous action, possibly rendering additional actions to follow.
To achieve enhanced flows of this sort, subscribe to the mechanic/actions/perform event topic. When a task includes this subscription, Mechanic will generate an event with that topic for every action that the task completes. This event will only ever be responded to by the task that generated it; it will never be sent to other tasks.
The mechanic/actions/perform subscription is commonly used with the Shopify action (with GraphQL mutations) and the HTTP action (for reading data from third-party APIs – see Working with external APIs).
The Echo action does not generate mechanic/actions/perform events.
Inspecting the context
Events with the topic mechanic/actions/perform are, by nature, always child events. As such, their event variable contains a reference to the event's parent. This means a task may use event.parent.data to access all the data that informed the construction of the action in question. (Note that only the previous 5 generations of parents are available.)
A mechanic/actions/perform event also provides task runs with an action variable (containing the same information available in event.data). This variable contains the original action object (including its type, options, and meta information), and data from the run in which the action was performed.
Common sources of information for followup task runs:
action.options — the original options defined for the action
action.run.ok — true or false, indicating the action's success
action.run.result — the value (if any) generated by the action run
action.run.error — the error (if any) raised during the action run
action.meta — the meta information given in the action's definition
It's important to specifically account for the mechanic/actions/perform topic when writing a task script, minding the fact that improper composition could result in an infinite loop.
Mechanic will step in and forcibly fail subsequent task runs that contain results identical to their predecessors.
Example
This example cycles between three different modes of operation, depending on the meta information recorded in the action definition. And, by checking on action.run.ok at the very beginning, the task is also able to "break" into failure-handling mode, in which an email is sent to an administrator.
Subscriptions
1
mechanic/user/trigger
2
mechanic/actions/perform
Copied!
Code
1
{% if action.run.ok == false %}
2
  {% action "email" %}
3
    {
4
      "to": "[email protected]",
5
      "subject": "Action failure",
6
      "body": {{ "Alert!<br><br>" | append: action.run.error | json }}
7
    }
8
  {% endaction %}
9
{% elsif event.topic contains "trigger" %}
10
  {% action %}
11
    {
12
      "type": "cache",
13
      "options": ["set", "foo", "bar"],
14
      "meta": {
15
        "mode": "first"
16
      }
17
    }
18
  {% endaction %}
19
{% elsif action.meta.mode == "first" %}
20
  {% capture mutation %}
21
    mutation {
22
      tagsAdd(id: "gid://shopify/Customer/1234567890", tags: ["processed"]) {
23
        userErrors { field, message }
24
      }
25
    }
26
  {% endcapture %}
27
​
28
  {% action %}
29
    {
30
      "type": "shopify",
31
      "options": {{ mutation | json }},
32
      "meta": {
33
        "mode": "second"
34
      }
35
    }
36
  {% endaction %}
37
{% elsif action.meta.mode == "second" %}
38
  {% action "echo", "done" %}
39
{% endif %}
Copied!
Techniques - Previous
Debouncing events
Next - Techniques
Working with external APIs
Last modified 1mo ago
Copy link
Edit on GitHub
Contents
Inspecting the context
Example