# 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.

<figure><img src="https://content.gitbook.com/content/cJYkTyk9qgh7aCR6dHIm/blobs/KZDahw6FIcRPneGBbFMk/image.png" alt=""><figcaption><p>Typical use of a split stream action</p></figcaption></figure>

#### 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.

#### 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.

{% hint style="warning" %}

#### 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.

{% endhint %}

#### 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)

#### 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

#### 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.