New Liquid filter: "parse_jsonl"

Useful when preparing stub data for bulk operations, the parse_jsonl filter accepts a multiline string in which each line contains a complete JSON object. It returns an array of parsed objects.

{% capture jsonl_string %}
{% endcapture %}

{% assign json_objects = jsonl_string | parse_jsonl %}

{{ json_objects | map: "email" | join: ", " }}
foo@bar.baz, bar@baz.qux

Read more

New "error_on_5xx" option for "http" actions

As a rule, Mechanic's "http" action considers any valid HTTP response to be a success. However, because HTTP responses with a 5xx status code should often be considered an error worthy of a retry, we now support a new "error_on_5xx" option. Set this option to true to have Mechanic mark 5xx responses as action errors, retrying the request for a total of up 5 attempts.

Read more

Automatic retries are now limited

When a run encounters an internal error (e.g. anything that isn't immediately surfaced to the user), Mechanic has historically retried the run (using an exponential backoff) until it either succeeds or reaches a known permanent error state.

As of today, Mechanic will now attempt a run at most 5 times.

Read more

Pending action runs for disabled or deleted tasks will now fail

Previously, a task's status did not affect its outstanding action runs. For example, a task in the middle of tagging 1000 products would continue tagging products, despite the task being disabled or deleted at only 500 products in.

Now, rather than continuing to perform pending action runs for deleted or disabled tasks, outstanding action runs will fail with a descriptive message.

However, action runs that were started before the task was deleted or disabled will be completed, rather than being aborted mid-performance.

Mechanic now detects and prevents Shopify update loops

In some cases, it's possible for an update to a Shopify resource to trigger an update event (e.g. "shopify/products/update"), resulting in a task run that performs a "shopify" action updating that same Shopify resource, resulting in an identical task run and an identical "shopify" action.

This infinite loop can – and should! – be prevented by the task developer, by detecting when a resource should have an update applied, and when it should not.

However, in cases when a loop does emerge, Mechanic will now step in and pause the offending actions.

Read more

Perform action runs in sequence

It's now possible to configure tasks for sequenced execution of task runs, rather than parallel execution. Additionally, you may choose to have the sequence halted when an action run fails.

These options are opt-in – there are no changes to the default execution of any runs.

Read more

New action: "files"

The "files" action supports any of Mechanic's existing methods of generating files (PDFs, zip archives, downloading from URL, etc), taking the resulting file data and making it available at a temporary, private URL.

Use this feature to compile a file, then send the file's URL to another service or user. Best use case we've seen so far: automatically printing generated PDFs, with Printnode. :)

Read more

Use "url" to retrieve files for email attachments, or for FTP uploads

The new "url" file generator can be used with the "email" and "ftp" actions to fetch resources from any URL, before then sending them along as email attachments or FTP uploads.

This makes it simple to, for example, sell PDF courses without revealing where they're hosted – simply upload the PDF to a secret location, and configure Mechanic to retrieve that file and email it out to anyone who purchases it.

Read more

Introducing cache endpoints

Cache endpoints allow you to publish the data you store in Mechanic's cache, making it available via a private JSON API.

Like webhooks, cache endpoints may be called from your online storefront (and from other origins). This means that Mechanic is now a flexible way to generate, collect, or transform data into something you can pull in to your online customer experiences. Paired with webhooks, you may now send data into Mechanic for processing and then poll the appropriate cache endpoint until processing is complete – a closed loop.

To use cache endpoints, use the "cache" action to store your data in the Mechanic cache. Then, use your Mechanic settings to create a cache endpoint, configured with the cache key you're using for storage.

Read more

New event topics: mechanic/scheduler/15min, 30min

Our existing mechanic/scheduler/10min topic is now joined by mechanic/scheduler/15min and mechanic/scheduler/30min, for schedules that require running every 15 minutes or every half hour. :)

Read more