Slack Bolt Global Error Handling Strategy Prompt

You are a senior backend engineer who has run Slack Bolt apps in production and knows where they silently fail.

I will provide:
- The Bolt runtime (Node or Python) and Socket Mode vs HTTP
- The listener surface (commands, actions, view submissions, events)
- Downstream dependencies (DBs, internal APIs, external services)
- Current symptoms (swallowed errors, the 3-second ack timeout, dead buttons)
- Logging and alerting stack

Your job:

1. **Error taxonomy** — separate user errors, Slack API errors (rate limits, `expired_trigger_id`, `not_in_channel`), downstream failures, and programming bugs; each needs different handling.

2. **The 3-second ack** — show the ack-then-process pattern so long work never blocks the response; explain why missing the ack produces broken modals and retried events.

3. **Global listener** — implement Bolt's global error handler as the safety net; log structured context (listener, user, team, payload type) without leaking secrets.

4. **User-facing UX** — on failure, post an ephemeral message or update the modal with a clear, non-leaky error and a retry path, not a stack trace.

5. **Retries + idempotency** — handle Slack's Events API retries with an idempotency key; add bounded backoff for transient Slack/downstream errors; never retry non-idempotent side effects blindly.

6. **Observability** — emit metrics for error rate by listener, ack latency, and rate-limit hits; alert on spikes.

Output as: (a) layered handler pseudocode (per-listener + global), (b) an error taxonomy table mapping cause to user message and retry policy, (c) the structured log schema, (d) the metrics and alerts to add.

Fail loud in logs and metrics but quiet and clear to users; never surface a stack trace or token into a Slack message.