0.3.0 ✔️

Summary

This release features more control over trigger-related system events, a new output node to explicitly configure flow output, loop protection for graph flows, and caching for webhooks and links. Note potential breaking changes for webhook configuration.

Trigger-related events

Release 0.2.4 added support for configuring per-event retention periods within event nodes. This release adds similar customization for both event and schedule triggers, which provide control over whether certain trigger-related system events are created, and for how long those system events are retained.

This is very useful for cases where a Sirveo server’s automatic event cleanup is disabled, typically because historic audit-ability is important. Those accumulating trigger.*.ok and trigger.*.error system events can now be reduced or eliminated, as needed.

Flow output control

A new output node is available in graph and task flows. This node explicitly configures a flow’s output data. It can be used at any point in a flow to set (or replace) a flow’s output data. Technically, when an output node runs in a flow, the flow engine will use it’s input as the flow’s output data. When a flow has no output node, the default behaviour still applies, which is to use the output of the last node as the output of the flow.

Previously, graph and task flows had to be arranged to accommodate this default behaviour, as there was no way to change it. The new output node provides convenient uses:

• It can simplify the arrangement of graph and task flows, in some cases
• When used early in a flow, it can configure some default flow output
• It allows flow to perform additional work after it’s output has been finalized

In order to implement the output node, an inconsistency had to be resolved in how the flow engine treats flow output data. Previously, both graph and task flows could produce more than one output data items. Only a webhook with output mode all could take advantage of that fact. Subflow and subflow loop nodes would only use the last output item of it’s target flow. As of 0.3.0, a flow produces one output, according to the default behaviour, or use of the new output node. This change resulted in breaking change for webhook output modes (see below).

Webhook output mode changes

This release simplifies webhooks with only two output modes, none, and flow. The latter uses the output of the target flow as the HTTP response body of the webhook.

In previous releases, webhooks supported output modes first, last and all. These have become redundant with the addition of the new output node (see above).

Here’s how to implement the old behaviors in Sirveo 0.3.0;

Old output mode	Alternative
first	Use the output node
last	Rely on default flow behaviour, or use the output node
all	A flow may produce array output data directly, with or without an output node

Graph flow loop protection

Sirveo’s flow engine handles the processing of graph flows in a recursive manner. This means that there is no technical limitation on handling loops in graph flows, as long as a loop does not start with the first node in the graph. While useful in some cases, it also means that mistakes in the design of a cycling graph flow could cause repeating loops.

To prevent such mistakes, a new flow engine feature prevents unbounded loops in graph flows. Technically, every connection between two nodes in a graph flow results in the flow engine performing a data routing operation. With the new constraint, the flow engine limits data routing operations to number of node connections + 20, for any single graph flow execution. This is a good balance between allowing some cycles, while preventing unbounded execution. For example, if a graph flow has 10 connections, it could repeat any part of itself up to 30 times before the flow engine will abort it’s execution.

If you have a use case which requires more cycles, use a subflow node to run a graph flow more than once.

Caching webhooks and links

The server would previously perform database interaction when executing flows via webhooks and links. Webhook and link records are now cached, with appropriate and transparent cache invalidation when they change.

This enhancement can significantly improve HTTP throughput for flows without external network latency (e.g. HTTP) or database interaction (e.g. persistent KV store interaction).

An internal benchmark that measures webhook throughput previously averaged around 5000 requests per second. This benchmark now reaches an average of 42,000 requests per second, on the same hardware.

Breaking changes

This release includes two breaking changes, both related to webhooks. For a smooth upgrade, follow the steps in the upgrade guides below.

 

• ⚠️ Webhook output modes first, last and all have been replaced with a new output mode flow

Upgrade Guide

When upgrading to 0.3.0, the automatic database migration changes the output mode of existing webhooks as follows:

Old output mode	New output mode
all	flow (potentially breaking)
first	flow (potentially breaking)
last	flow (backwards compatible)
none	none (no change)

If your existing webhooks uses output modes all or first, these steps are recommended prior to a 0.3.0 upgrade.

1. Change the output mode of all webhooks to last
2. Test the webhooks for correct behaviour

Note that the behaviour of first is easily re-implemented with the new output node. Re-implementing the previous all behaviour will likely require the use of a JS Code node, together with the new output node.

 

• ⚠️ Webhooks with output mode none now contains no response body.

Upgrade Guide

Webhooks using output mode none previously used an empty JSON object in HTTP response bodies.

If any upstream HTTP client relies on this empty JSON object, the previous behaviour can be re-implemented after a 0.3.0 upgrade:

• Change the webhook’s output mode from none to flow
• In the webhook’s target flow, add an output node somewhere, and configure it with an empty JSON object

Deprecations

None, but please note the deprecation notice from 0.2.9, about an upcoming change in server variable behaviour.

Fixes

No known issues.

Features

Event triggers

• ⚡event triggers: new setting to configure system event retention period
• ⚡event triggers: new setting to disable trigger.event.ok system events
• ⚡event triggers: new setting to disable trigger.event.error system events

Schedule triggers

• ⚡schedule triggers: new setting to configure system event retention period
• ⚡schedule triggers: new setting to disable trigger.event.ok system events
• ⚡schedule triggers: new setting to disable trigger.event.error system events

Nodes

• 💠🔥 output node: explicitly configure flow output in graph and task flows

Enhancements

Performance

• 🔼🔥 server: webhooks and links are now cached in server memory.

Nodes

• 🔼💠 schedule node: add support for new schedule trigger settings (see above)

UI: General

• 🔼 ui: webhook configuration has more complete descriptions
• 🔼 ui: the notes at the bottom of trigger views has been improved and simplified

UI: Flow editor

• 🔼 ui: flow editor - the node selection list is now organized by category
• 🔼 ui: flow editor - when testing task flows, duplicate node outputs are hidden
• 🔼 ui: flow editor - when testing web flows, blank input data for nodes is shown
• 🔼 ui: flow editor - when testing web flows, internal node outputs are classified with the correct destination (internal, not Flow output)

Internal

• 🔼 engine: data routing in graph flows are now limited to number of node connections + 20, to prevent accidental loops

• ⚙️ db: tables trigger_schedule and trigger_event has new columns:

  • event_retention
  • disable_ok_events
  • disable_error_events