chat.postMessage Retries Without Duplicate Writes

Preventing Duplicate Slack Messages When Retrying chat.postMessage After Timeouts

Confirmed fact: Slack’s chat.postMessage Web API does not honor any client‑supplied deduplication identifier (e.g., client_msg_id or a custom field). The only identifiers returned are the server‑generated ts and optional thread_ts. Therefore a retry after a timeout or 5xx error can create a second identical message if the original request was already processed.

Likely explanation

When a network timeout occurs, Slack may have already received and stored the message before the client’s timeout fired. Because the API offers no server‑side idempotency, a blind retry will cause a duplicate write. The same risk applies to retries after 5xx responses; 429 Retry-After retries share the risk if the original request succeeded before the rate‑limit response was sent.

Steps to avoid duplicate writes

1. Send chat.postMessage with exponential backoff for 5xx and network timeouts, and honor Retry-After on 429.
2. If the attempt ends in a timeout (no response received) or you receive a 5xx, immediately query conversations.history for the target channel, limiting results to the most recent messages (e.g., limit=100).
3. Look for a message whose text matches the notification you just attempted to send (or, if you include a unique marker in the text, match that marker). If a matching message is found, treat the original request as successful and skip the retry.
4. If no matching message appears in the history window, safely retry the chat.postMessage request using the same backoff schedule.
5. For 429 responses, wait the specified Retry-After interval before retrying; the same history check can be applied after the wait if you suspect the original request may have succeeded.

Missing diagnostic detail

To guarantee that conversations.history will still contain the original message, you need to know your workspace’s message retention setting (default 30 days). If retention is shorter than the expected retry window, the history query could miss the message and cause a false‑positive retry. Please confirm the retention period for the channel or workspace before relying on this deduplication method.