Feature: acknowledging requests without an HTTP response

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

Begin by tracing the Bolt handler response lifecycle around ack() and reviewing the interaction payload's ack_url behavior described here. Done means Slack receives an acknowledgment within 3 seconds while long-running work remains awaited and durable, without requiring the SQS workaround.