0.2.3 ✔️

Summary

This is a performance-focused release. Leveraging the in-memory stores introduced in 0.2.0, the server now caches flow definitions and server variables in memory. This feature removes an IO constraint for successive flow executions, which can improve throughput for inbound HTTP requests by around 80%.

Breaking changes

• ⚙️ event data for the following system events no longer contains the flow_rev property:

  • trigger.event.error
  • trigger.event.ok
  • trigger.schedule.error
  • trigger.schedule.ok

Upgrade guidance

If you have event-triggered flows which specifically use the flow_rev property on these events, those flows will need to be updated accordingly.

Enhancements

• 🔼 ui: flow client UI has max width increased from 512px to 900px
• 🔼 ui: testing web flows in the editor now displays the last 5 steps, instead of 10

Event triggers

• ⚙️ event and schedule triggers are no longer automatically disabled when their target flows cannot be loaded

Context

With the previous behavior, temporary or intermittent problems with database connectivity could cause triggers to be automatically disabled. The consequence of this change would result in more trigger error events, but without the need to manually re-enable triggers.

Flow engine

• 🔼⚙️ engine: session data for web flows are now persisted in the server’s internal store for 60 minutes, instead of being AES-encrypted in client responses

Context

The content of the $data store in web flows must persist between client requests, without being visible to clients (browsers), since users may populate it with sensitive data.

Previously, this was achieved by AES-encrypting the $data store contents in client responses, using a short-lived secret which clients did not have sufficient information to reconstruct or derive. While this approach did not require server resources (storage/memory) to store $data store content between web flow interactions, it allowed clients to determine that more or less encrypted data was present between interactions with web flows.

With this enhancement, HTTP responses to clients (browsers) that interact with web flows contains zero information about the $data store, which is now persisted in the server’s memory and database. This temporary data is automatically deleted from server storage, 60 to 75 minutes after a client performs it’s last interaction with a web flow.

Server internals

• ⚡⚙️ server: flow definitions are cached in memory for 60 minutes
• ⚡⚙️ server: variables are cached in memory for 60 minutes
• ⚙️ server: flow definition changes appropriately invalidates cached flow definition data
• ⚙️ server: variable changes appropriately invalidates cached variable data

Context

This feature is a performance enhancement that benefits flow executions via webhooks, links, event triggers and schedule triggers.

Previously, every flow execution would result in database interactions to (1) retrieve flow definitions and (2) server variables. These database round-trips would introduce a network-bound or IO-bound constraint on how fast the server could execute flows.

With this feature, for example, 100,000 HTTP requests to a webhook will result in only one or two database queries for the first request.

Cache invalidation is handled transparently when flow definitions or server variables are updated or removed. There is a very small moment (some microseconds) between a database update and a cache update or invalidation. The probability of stale cache reads is not zero, but sufficiently small to be negligible in practice.