# 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="/files/E7Zup5bbIu8fWZd2G0HY" 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.helmut.de/helmut4-releases/helmut4-components/streamdesigner/nodes/actions/misc-21/split-stream-action.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.