search

Split Stream Action

The Split Stream Action node splits a stream into two execution paths:

  • a synchronous path (must finish quickly)

  • an asynchronous path (can run longer)

This node is required whenever a stream may exceed the 60-second execution limit. If the synchronous part does not complete within 60 seconds, the stream will fail. The asynchronous path can run longer than 60 seconds, but it still executes sequentially within itself.

Typical use of a split stream action

hashtag
Why This Node Exists

Long-running operations such as copying, rendering, or multi-step processing (especially in IO, CO, or HK contexts) cannot reliably finish within 60 seconds. By splitting the stream, you keep the trigger response fast while continuing heavy work safely in the background.

hashtag
Recommended Usage

1) Keep the sync path short All nodes on the synchronous path must finish within 60 seconds.

2) Add a short Sleep on the sync path If the synchronous path has no meaningful actions after the split, connect it to a Sleep node (e.g., ~123 ms). This forces the dashboard to create a debug log immediately. Otherwise, the log may only appear after the asynchronous path finishes — which is problematic if the async part fails early.

3) Put long processes into the async path Copying, transcoding, rendering, and other multi-node procedures should run on the asynchronous path.

circle-exclamation

hashtag
Important Restrictions

  • Do not use this node in FX streams. It may cause issues with certain FX triggers (e.g., create/open project).

  • Do not use multiple Split Stream nodes in one stream. Only one instance should be used per stream.

  • If you still hit timeouts: Split the logic into multiple separate streams and run them sequentially via the trigger event instead of trying to chain everything in one stream.

hashtag
Behavior

  • Creates a synchronous and an asynchronous branch

  • Sync branch must complete within 60 seconds

  • Async branch can exceed 60 seconds and continues processing in the background

  • The async branch is still executed sequentially (synchronously within itself)

hashtag
Typical Use Cases

  • long file copies (IO/CO/HK)

  • render and transcode workflows

  • multi-step ingest / delivery processing

  • operations where progress/log visibility matters in the dashboard

hashtag
Practical Summary

Use this node when you need to start heavy processing without risking the 60-second stream timeout. Keep the sync side minimal (and ideally end it with a short Sleep), and run the real work on the async side.

Last updated