bolt-python: Problem of receiving two or more duplicate messages when sending a message through chat_postMessage()

Problem of receiving two or more duplicate messages when sending a message through chat_postMessage()

I’m using slack_bolt and when I send a message through chat_postMessage(), I get a problem with receiving a message with two or more duplicate messages. The message is sent as a combination of blocks, and the size of the block exceeds 4000 bytes. I tried debugging, but it doesn’t seem to retry. An example of a block is shown below.

ex1) app.client.chat_postMessage(blocks=, channel=)
ex2) blocks = [{'elements': [{'text': '*aaaaaaaaaa*', 'type': 'mrkdwn'}],
             'type': 'context'},
            {'elements': [{'alt_text': 'cute cat',
                           'image_url': 'https://cdn-icons-png.flaticon.com/512/752/752664.png',
                           'type': 'image'},
                          {'text': f'{"a"*37}',
                           'type': 'mrkdwn'}],
             'type': 'context'},
            {'elements': [{'text': f'>```{"a"*3920}```',
                           'type': 'mrkdwn'}],
             'type': 'context'},
            {'elements': [{'alt_text': 'cute cat',
                           'image_url': 'https://cdn-icons-png.flaticon.com/512/752/752665.png',
                           'type': 'image'},
                          {'text': f'{"a"*39}',
                           'type': 'mrkdwn'}],
             'type': 'context'},
            {'elements': [{'text': f'>```{"a"*100}```', 'type': 'mrkdwn'}],
             'type': 'context'}]

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 22 (5 by maintainers)

Commits related to this issue

Most upvoted comments

@ls-urs-keller @colinmcparland @g-bakas @kacper1112

Oddly enough, I discovered that if both “blocks” and “text” were set, the messages were not duplicated. I use it as a workaround.

eg)

{
  "channel": "xxx",
  "text": "no-use",
  "blocks": [{...}]
}

I reached out to Slack’s support about this and got a response:

This is a known bug with messages which are over 4039 characters of text combined. The expected behaviour is that messages over 4000 characters should get split up and posted across multiple messages, up to a maximum of 40,000 characters (which should be split into up to 10 messages.)(https://api.slack.com/changelog/2018-04-truncating-really-long-messages / https://api.slack.com/changelog/2018-04-truncating-really-long-messages). It seems our logic on splitting up these messages is causing duplicates of the first message to be posted instead.

I’m afraid we don’t have a timeline of how long it may take to resolve this issue, but I shall be sure to update you here as soon as there’s any word on it. In the meantime I would recommend splitting up any messages longer than 4000 characters on your end before sending.

Posting this here as I see more users are looking for some information on the problem.

I have the same issue with a and can reproduce it this way:

curl -v -H "Content-type: application/json; charset=utf-8" \
  --data "@trial.json"  \
  -H "Authorization: Bearer ${SLACK_ACCESS_TOKEN}" \
  -X POST https://slack.com/api/chat.postMessage

trial.json.zip

Using this curl you will see that the messages are duplicated in the channel.

If you remove 1 character from the end of the message (remove the 5) there are no duplicates. If you create even bigger messages you get 3 or 4 times the same message.

This must be related to the slack API and how it handles sizes. @seratch I can post this in a different place this doesn’t seem to be linked to the client library, but is a bug in the slack API. We observe this since the 30th March 2023.

Seeing the same issue with the direct slack API call, how do you send an ack() to the slack API?

@ls-urs-keller we are experiencing the same issue, please let me know where you end up posting this, thanks!

I am experiencing the same issue. Any news on this @seratch ?

Thanks in advance.

@sh4n3e The only possible direct cause that we can think of is that your bolt-python app receives the message events several times, so that the same chat.postMessage API call is executed twice or more. The common reason of this is that your bolt-python app does not respond to message event payload data request from Slack within 3 seconds for some reason and then the Slack API server retries the same request up to 3 times.

In the case of app.event / app.message listeners, you don’t need to explicitly call ack() method within 3 seconds in the listeners. bolt-python framework does ack() for you under the hood. However, if any of the following situations arises, acknowledging within 3 seconds may fail:

  • Your app have process_before_response=True in App constructor for FaaS compatibility and your listener takes more than 3 seconds to complete
  • Your app received message event requests but failed to send an HTTP response to it for some reason
  • If you use Socket Mode, your WebSocket connection might be unstable for a reason such as network glitch

To figure out what’s happening on your app, I would suggest enabling debug-level logging for your bolt-python app. Please refer to https://slack.dev/bolt-python/concepts#logging to learn how to configure loggers. Also, if you have access logs on the load balancer or frontend web server (e.g., nginx, Apache HTTP server), checking whether message event requests are properly responded with 200 OK and how long the server takes to respond should be helpful for you.

I hope that you will find the solution for it soon!

Hi @sh4n3e thanks for writting in!

In order to try and reproduce this on my end would it be possible for you to share a snippet of your source code, and what the duplicate messages looks like.

But here are 2 things to look out for:

  • Depending on the handler you are implementing, ensure that the ack() function is called before client.chat_postMessage similar to this example where ack() is called before client.views_open.
  • Ensure that your handler is not hanging indefinitely, a retry request could be sent to your app if no response is received