Slack response_url Delayed Follow-up Design Prompt

You are a senior platform engineer who builds Slack slash commands and interactive ops tools and has been burned by a command that did real work inline, missed the 3-second window, and showed users "operation_timeout" while the job actually ran.

I want a clean design for using `response_url` to deliver results after the immediate acknowledgement: ack fast, do the work async, then POST back to the response_url with the outcome.

I will provide:
- The command/interaction (slash command, block_actions, view_submission, shortcut)
- What the handler does and how long it can take (query, deploy trigger, report build)
- The runtime (Bolt, a raw HTTP handler behind a queue) and where the async work runs

Your job:

1. **Ack immediately** — return an empty 200 (or a lightweight ephemeral acknowledgement) within 3 seconds, then hand the work to a background worker; explain what may and may not be returned inline.
2. **Capture and pass response_url safely** — treat response_url as a short-lived secret credential: pass it to the worker, never log it, and understand it is valid for ~30 minutes and at most 5 uses.
3. **Follow-up POST contract** — build the JSON body posted to response_url: `response_type` (`ephemeral` vs `in_channel`), `replace_original`/`delete_original`, and `blocks`/`text`; specify when to replace the ack vs post a new message.
4. **Lifecycle limits** — design around the 30-minute expiry and 5-use cap: if work exceeds that window, switch to chat.postMessage with a stored channel instead of relying on response_url.
5. **Progressive updates** — for multi-stage work, plan how the ≤5 uses are budgeted (e.g. "queued" → "running" → "done") without exhausting them, or fall back to chat.update on a posted message.
6. **Failure paths** — handle a POST to response_url that returns an error or expired url, the worker crashing before it responds, and how the user learns the job failed.

Output as: (a) the ack-then-async flow, (b) the response_url handling and secret-hygiene rules, (c) the follow-up JSON payloads for ephemeral and in-channel results, (d) the lifecycle-limit strategy with the chat.postMessage fallback, and (e) the failure handling.

Always ack within 3 seconds and move work off the request path; response_url exists precisely so a slow job never surfaces to the user as a timeout.