Package
@slack/web-api
Description
Summary
We are building a Slack integration that uses chat.startStream and chat.appendStream to provide users with live progress updates while our backend performs long-running workflows.
Currently, a stream is automatically closed after approximately 5 minutes, even if we continue sending updates via chat.appendStream during that time.
This makes it difficult to provide a seamless streaming experience for workflows that legitimately take longer than a few minutes.
Feature request
Please make the timeout for chat.startStream configurable, or alternatively allow the stream lifetime to be extended while it is actively receiving chat.appendStream events.
For example, an optional parameter such as:
{
"stream_timeout_seconds": 1800
}
or a similar mechanism to keep an active stream alive would allow applications to support longer-running workflows without interruption.
Why this is needed
Many real-world automation workflows cannot reasonably complete within five minutes.
One example is an automated incident investigation:
- A production issue is detected.
- A CI/CD pipeline is triggered to collect diagnostics.
- The application waits for the pipeline to complete.
- The generated logs and artifacts are downloaded.
- The logs are analyzed by an LLM.
- A root cause is identified.
- A server is restarted.
- Health checks are executed until the service becomes healthy again.
- A final report and recommendation are generated.
Throughout this workflow, we continuously send progress updates using chat.appendStream so users can follow what is happening in real time.
However, if the workflow exceeds five minutes, the stream closes automatically despite the fact that it is still actively receiving updates.
Current behavior
chat.startStream creates a stream.
- The application periodically calls
chat.appendStream with additional progress.
- After roughly five minutes, the stream is automatically closed.
- Additional streaming updates can no longer be appended, forcing the application to switch to another mechanism or create a new message.
This interrupts what appears to the user as a single continuous operation.
Expected behavior
One of the following approaches would solve the issue:
- Allow the timeout to be configured when calling
chat.startStream.
- Automatically extend the lifetime of a stream whenever
chat.appendStream is received.
- Provide a dedicated API to renew or extend an existing stream before it expires.
Any of these approaches would enable applications to support legitimate long-running operations while preserving a single continuous streaming experience for users.
Why this matters
Streaming is an excellent UX for AI-powered workflows because users can observe progress as it happens instead of waiting for a final result.
Many enterprise workflows—including incident response, infrastructure automation, CI/CD diagnostics, and deployment remediation—can easily exceed five minutes. Having streams terminate regardless of ongoing activity makes it difficult to build rich, interactive experiences around these scenarios.
Allowing applications to control (or extend) the stream lifetime would make chat.startStream much more suitable for complex, real-world automation workflows.
Thank you for considering this enhancement!
Alternatives Considered
No response
Package
@slack/web-api
Description
Summary
We are building a Slack integration that uses
chat.startStreamandchat.appendStreamto provide users with live progress updates while our backend performs long-running workflows.Currently, a stream is automatically closed after approximately 5 minutes, even if we continue sending updates via
chat.appendStreamduring that time.This makes it difficult to provide a seamless streaming experience for workflows that legitimately take longer than a few minutes.
Feature request
Please make the timeout for
chat.startStreamconfigurable, or alternatively allow the stream lifetime to be extended while it is actively receivingchat.appendStreamevents.For example, an optional parameter such as:
{ "stream_timeout_seconds": 1800 }or a similar mechanism to keep an active stream alive would allow applications to support longer-running workflows without interruption.
Why this is needed
Many real-world automation workflows cannot reasonably complete within five minutes.
One example is an automated incident investigation:
Throughout this workflow, we continuously send progress updates using
chat.appendStreamso users can follow what is happening in real time.However, if the workflow exceeds five minutes, the stream closes automatically despite the fact that it is still actively receiving updates.
Current behavior
chat.startStreamcreates a stream.chat.appendStreamwith additional progress.This interrupts what appears to the user as a single continuous operation.
Expected behavior
One of the following approaches would solve the issue:
chat.startStream.chat.appendStreamis received.Any of these approaches would enable applications to support legitimate long-running operations while preserving a single continuous streaming experience for users.
Why this matters
Streaming is an excellent UX for AI-powered workflows because users can observe progress as it happens instead of waiting for a final result.
Many enterprise workflows—including incident response, infrastructure automation, CI/CD diagnostics, and deployment remediation—can easily exceed five minutes. Having streams terminate regardless of ongoing activity makes it difficult to build rich, interactive experiences around these scenarios.
Allowing applications to control (or extend) the stream lifetime would make
chat.startStreammuch more suitable for complex, real-world automation workflows.Thank you for considering this enhancement!
Alternatives Considered
No response