Skip to content

0.3.4 ✔️

Summary

This release introduces minor but useful enhancements to schedule triggers, webhooks and flow stores. Webhooks now accept any valid JSON data in inbound request bodies. Schedule triggers support a new @every syntax, in addition to cron expressions. Flows may now schedule themselves to run later, via the schedule node. Also, backwards compatibility for 0.2.9’s deprecated server variable behaviour has been removed.

The schedule trigger guide covers self-scheduling flows and the @every syntax, with new scheduling tutorials.

Minor flow store additions are fully documented in the flow store reference.

Breaking changes

  • ⚠️ removed backwards compatibility for 0.2.9’s deprecated server variable behaviour

Deprecations

None.

Fixes

  • 🐞 ui: fix that closing a task flow in the flow editor could, in some cases, cause the UI to become unresponsive
  • 🐞 ui: fix that web flow password input blocks didn’t display correctly

Features

Faster scheduling 🔥

  • ⚡ schedule triggers support a new @every syntax
  • ⚡ schedule triggers can schedule more frequently (60 to 5 seconds)

Self-scheduling flows 🔥

  • ⚡ flows may schedule themselves (with a 30-second minimum delay)

Flow store changes

  • ⚡ the metadata store has a scheduling_flow_id property when a flow is executed by another flow via the schedule node
  • ⚡ the metadata store store has a node_errors property, which counts the number of times nodes produced output on an error output channel
  • ⚡ the input and input metadata stores are available in task flow conditions

Enhancements

General

  • 🔼 ui: schedule trigger configuration has examples of @every syntax
  • 🔼 ui: minor UX enhancements to schedule trigger list
  • 🔼 ui: flow editor - do not apply a default layout to web flows that doesn’t have one
  • 🔼 api: retrieval of once-off schedule triggers displays the most recent 200 triggers

Webhooks

  • 🔥 webhooks now allow any valid JSON data in request bodies of POST, PUT, PATCH and DELETE requests.

Internal

  • ⚙️ the server scheduler internals has more robust mechanisms to prevent the same schedule trigger from executing concurrently, or within 4 seconds of it’s prior execution. Details here.