Summary
Slack Bolt SDK handlers block the HTTP response until the handler returns. When Bolt runs inside an AWS Lambda with durable execution, the Lambda must finish before Slack receives a response.
That conflicts with Slack’s 3-second timeout and with durable workflows that need to run long-running tasks after an early acknowledgment.
Problem
Slack’s 3-second timeout
Slack expects an HTTP response within 3 seconds for:
- Modal submissions (
view_submission)
- Slash commands
- Other interactive payloads, such as buttons
If the response is late, Slack shows errors like “We had some trouble connecting. Try again?” and may retry.
Bolt’s request/response model
Bolt handlers are written as async functions. The HTTP response is sent only when the handler returns:
app.view('my_modal', async ({ ack, view, body }) => {
await ack({ response_action: 'update', view: processingView });
// Handler must return before Slack receives the response
await longRunningWork(); // Blocks the response
});So any work done after ack() still delays the response.
Durable execution requirements
With AWS Durable Execution (or similar runtimes), all work must be part of the durable workflow. Background or fire-and-forget work is not allowed; everything must be awaited so the runtime can checkpoint and replay correctly.
Resulting conflict
Slack needs a response within 3 seconds.
Bolt sends the response only when the handler returns.
Durable execution requires all work to be awaited before the Lambda completes.
Long-running work (e.g. LLM calls, external APIs) can exceed 3 seconds.
So we cannot both acknowledge Slack quickly, and run long-running work inside the same durable Lambda execution.
Desired behavior
We’d like a way to:
Acknowledge early – Send a response to Slack (e.g. “processing”) within 3 seconds.
Continue durable execution – Run long-running work in the same Lambda invocation, with proper checkpointing and replay.
Current workaround
We currently use SQS to decouple:
Bolt handler acks immediately and enqueues the payload to SQS.
A separate SQS-triggered Lambda (or the same Lambda with a different trigger) runs the long-running work with durable execution.
This works but adds:
- Extra infrastructure (SQS, event source mapping)
- Two Lambda invocations per interaction
- More moving parts and failure modes
Feature request: ack_url in the interaction payload
When a POST request is made to the ack_url Slack receives acknowledgment of the interaction from the Slack app and does not display any error messages to the user
The Slack app can then continue with long running processes
Summary
Slack Bolt SDK handlers block the HTTP response until the handler returns. When Bolt runs inside an AWS Lambda with durable execution, the Lambda must finish before Slack receives a response.
That conflicts with Slack’s 3-second timeout and with durable workflows that need to run long-running tasks after an early acknowledgment.
Problem
Slack’s 3-second timeout
Slack expects an HTTP response within 3 seconds for:
view_submission)If the response is late, Slack shows errors like “We had some trouble connecting. Try again?” and may retry.
Bolt’s request/response model
Bolt handlers are written as async functions. The HTTP response is sent only when the handler returns:
So any work done after ack() still delays the response.
Durable execution requirements
With AWS Durable Execution (or similar runtimes), all work must be part of the durable workflow. Background or fire-and-forget work is not allowed; everything must be awaited so the runtime can checkpoint and replay correctly.
Resulting conflict
Slack needs a response within 3 seconds.
Bolt sends the response only when the handler returns.
Durable execution requires all work to be awaited before the Lambda completes.
Long-running work (e.g. LLM calls, external APIs) can exceed 3 seconds.
So we cannot both acknowledge Slack quickly, and run long-running work inside the same durable Lambda execution.
Desired behavior
We’d like a way to:
Acknowledge early – Send a response to Slack (e.g. “processing”) within 3 seconds.
Continue durable execution – Run long-running work in the same Lambda invocation, with proper checkpointing and replay.
Current workaround
We currently use SQS to decouple:
Bolt handler acks immediately and enqueues the payload to SQS.
A separate SQS-triggered Lambda (or the same Lambda with a different trigger) runs the long-running work with durable execution.
This works but adds:
Feature request: ack_url in the interaction payload
When a POST request is made to the ack_url Slack receives acknowledgment of the interaction from the Slack app and does not display any error messages to the user
The Slack app can then continue with long running processes