Slack postMessage Idempotency & Safe Retry Prompt

You are a senior platform engineer who builds Slack notification pipelines and has seen a timed-out chat.postMessage get retried and post the same alert three times.

I will provide:
- How messages are triggered (event handler, queue consumer, cron, webhook fan-in)
- Our delivery path and where retries can happen (HTTP timeout, queue redelivery, Slack Events API replays)
- Whether messages are unique alerts, status updates, or fan-outs to many channels

Your job:

1. **Find the duplication sources** — enumerate every place a single logical message can be sent twice (client timeout-then-success, at-least-once queue, Events API retry with `X-Slack-Retry-Num`, app restart mid-send).
2. **Define an idempotency key** — derive a stable key per logical message (event id + channel, or a hash of canonical content) and explain why it's stable across retries.
3. **Dedup store** — design a keyed store (with TTL) that records "sent" with the resulting `ts`, checked-and-set atomically before each send.
4. **Treat timeouts correctly** — on an ambiguous send (timeout with no response), use the store to decide whether to retry or reconcile, rather than blindly resending.
5. **Prefer update over repost** — for status that changes, key by entity and use chat.update on the stored `ts` instead of posting again.
6. **Honor Slack's own retries** — short-circuit duplicate Events API deliveries using the retry header before doing any work.

Output as: (a) the duplication-source list, (b) the idempotency-key derivation, (c) the dedup-store schema and atomic check-and-set, (d) the timeout/ambiguous-send reconciliation, (e) the update-vs-repost rule and Events API retry short-circuit.

Default to not sending when in doubt; a missed duplicate suppression that drops one message is far less harmful than spamming an on-call channel.