New Liquid filters: gzip, gunzip

For scenarios in which tasks must work with gzipped data, we now offer two new Liquid filters: gzip, and gunzip. They work exactly the way they sound. :)

Read more

(More) Important changes to tasks and Shopify API versions

As we get (much) closer to October 1, and the sunsetting of version 2019-10, a few things have become clearer about how Shopify API versions should be handled, as each version approaches the end-of-support threshold. :)

To that end, effective immediately, tasks configured for a Shopify API version that has 30 days or left of Shopify support will be silently upgraded to the next available version.

Saliently, this means that tasks on version 2019-10 are now operating on 2020-01, effective immediately. And, while Shopify will support version 2020-01 until January 1 of 2021, Mechanic tasks on that version will be moved to the next version (i.e. 2020-04) 30 days ahead of that date (i.e. on December 2 of 2020).

Additionally, tasks may no longer be configured for Shopify API versions that Shopify no longer supports, or versions that are within 30 days of being unsupported.

Read more

New event topics: shopify/disputes/*

Following Shopify's announcement of new webhooks for disputes, Mechanic now supports two new event topics: shopify/disputes/create, and shopify/disputes/update. Tasks subscribing to these topics receive a dispute variable, containing the dispute's information.

Read more

Update to collections.products

For tasks running on version 2020-01 or later of the Shopify API, Liquid references to collection.products will now return products ordered by their position in the collection.

This update makes it easier to migrate away from collection.collects or product.collects, which – as of version 2020-01 – no longer include collect objects for smart/auto collections.

Read more

Important changes to tasks and Shopify API versions

In anticipation of version 2020-10 of the Shopify API, we're making several important changes to how Mechanic interacts with Shopify API versions.

All changes below are effective immediately. The changes below do not modify the behavior of any existing tasks in any way.

  1. Newly-created tasks now default to the latest supported Shopify API version.
  2. A Shopify API version is now a required attribute of all tasks.
  3. Previously, Mechanic had a "platform default" version, of 2019-10. For tasks that did not have a Shopify API version set, this platform default was used. This concept did not age well, and we are removing it.
  4. In light of the changes above, all existing tasks that had no Shopify API version have had their versions set to 2019-10.

Again, these changes do not modify the behavior of any existing tasks.

Read more

Scheduled event and task runs may now be cancelled

Mechanic allows work to be scheduled for the future either via delayed subscriptions (e.g. mechanic/scheduler/daily+8.hours) or via "event" actions with a specified "run_at" time.

These scheduled runs may now be cancelled, using a new "Cancel" button that appears whenever a run is waiting for a future run time.

Task runs

Screen Shot 2020-08-25 at 10.31.13 AM.png

Event runs

Screen Shot 2020-08-25 at 10.32.04 AM.png

New data policy

Mechanic has a new data policy, defining data residency and retention.

Summary of residency policy

Mechanic's data residency practices are unchanged, but are now formally established: all data is stored in the US, on encrypted volumes.

Summary of retention policy

By default, event data (and all related run data) will be expunged 60 days after an event is completed (i.e. after all pending runs is complete for that event). If the event has descendants (i.e. child events, grandchild events, etc), the expungement of that event will be delayed until the 5th descendant generation has had its runs completed.

The retention policy is effective immediately for new store accounts, and will become effective September 1 2020 UTC for all store accounts.

Stores may request a different retention period by emailing

Read more

GraphQL variable support for the "shopify" action

The "shopify" action has a new, optional syntax that supports GraphQL variables. By providing a JSON hash of options, consisting of a "query" key and a "variables" key, you may now separate your inputs from the query itself, allowing both for query re-use and for variables in excess of Shopify's 50k-character limit for query strings.

This syntax is available in block form:

{% capture query %}
  mutation DeleteProduct($productId: ID!) {
      input: {
        id: $productId
    ) {
      userErrors {
{% endcapture %}

{% action "shopify" %}
    "query": {{ query | json }},
    "variables": {
      "productId": {{ product.admin_graphql_id | json }}
{% endaction %}

… and in tag form:

{% assign variables = hash %}
{% assign variables["productId"] = product.admin_graphql_api_id %}

{% action "shopify", query: query, variables: variables %}

This change does not impact existing uses of the "shopify" action.

Read more

New Liquid filter: parse_xml

Use parse_xml to transform an XML string into a nested hash, keyed by XML tag name. Useful for processing output from third-party APIs, either by responding to "http" actions, or by parsing content from inbound webhooks.

Read more

New Liquid filters: in_groups, in_groups_of

Borrowing from Rails, our Liquid implementation now supports in_groups and in_groups_of. These are particularly useful when performing work in batches, splitting (for example) an unknown number of mutations into batches of a specific size.

Read more