Error raised when sending message with blocks

[ateymour]

Slack API supports having "blocks" within "attachments". This can be confirmed in the documentation here and via the builder web tool here. But through this lib it seems to result in an error raised when sending the message or no message with None being returned.

This may be an issue of my object structure on my end but I'm unable to verify since there is very little documentation for this use case. If anyone can provide a simple working example of attachments with blocks inside that would be helpful

PS: I also tried using model blocks as suggested in this issue: https://github.com/slackapi/python-slack-sdk/issues/1189 And I followed this issue as well https://github.com/slackapi/python-slack-sdk/issues/986 to try and confirm if things are set up ok. Even with the model classes, it works ok without blocks in the attachments and fails to send anything with it.

Reproducible in:

To reproduce, create any attachment block and send it via chat_postMessage(). Then add a "blocks" tag as described by the documentation and try again. With the blocks param in the attachments, only the fallback text will be posted, or no message at all if there is no text, with None returned by the function.

The Slack SDK version

(Paste the output of pip freeze | grep slack)

Python runtime version

python=3.8 slack-sdk=3.18.1

[misscoded]

Hi @ateymour! Can you provide us with a snippet of code that includes the chat_postMessage() logic that is resulting in an error for you?

[seratch]

Also, you can use Block Kit Builder to learn what's wrong with your attachments that have blocks.

[ateymour]

I think I found the issue. The problem was actually the difference of behavior between the Block Kit Builder and the API. The issue was I was using a combination of current and legacy fields listed ("text" and "blocks") in the attachments documentation. https://api.slack.com/reference/messaging/attachments In the Block Kit Builder, this works out just fine, it seems to ignore one or the other. But when using this library it results in a silent error and None being returned.

[seratch]

@ateymour Thanks for sharing this but would you mind elaborating a bit more? If you can share the attachments / blocks that reproduce your situation, it'd be helpful for us to understand what you've mentioned. Also, if something on this SDK side can improve to mitigate developers' confusion for the future, we are happy to update the modules.

[ateymour]

Hi all, I was gonna make a simple example here but I'm unable to reproduce the issue exactly as it was. The combination of text + attachment does result in an error, but its not a silent one. eg. this works in the Block Kit Builder, and only produces This is a markdown block only:

{
    [
        {
            "color": "#f2c744",
            "text": "This is a test text message",
            "blocks": [
                {
                    "type": "section",
                    "text": {
                        "type": "mrkdwn",
                        "text": "This is a markdown block"
                    }
                }
            ]
        }
    ]
}

If I was to pass the dict to slack_sdk's chat_postMessage as an attachment (minus the lowest level {} brackets) it will not work, and it will raise an error. If I move the "text": "This is a test text message" section out of attachments and pass it as a standalone text parameter, it will work but it will produce both the text and the blocks in the message which is a different behavior than the Block Kit Builder.

In either case though I cant reproduce the silent errors when I tried to put together simple example, so I'm guessing some layer of our code was silencing the error messages which is why in a simple example I was putting together I did see an error. So at this point I'm not sure if this is a real bug or not anymore because it comes down to a simple behavior different between the two tools.

[kbroughton]

Thanks for raising this @ateymour . I hit the same issue and the docs are really insufficient and the error message isn't very helpful.

It appears that not all valid elements in block kit tool can be posted as a message, despite the fact that message preview works fine in the Block Tool.

In my case, the code failed when I included an input block and passed when i removed it. The input block was generated by the Block Kit tool and it looked fine when selecting "Message Preview".

		{
			"type": "input",
			"element": {
				"type": "plain_text_input",
				"action_id": "plain_text_input-action"
			},
			"label": {
				"type": "plain_text",
				"text": "Feedback",
				"emoji": true
			}
		}

The error was {'ok': False, 'error': 'invalid_blocks'}

If messages are not meant to support input fields, then the Message Preview should fail in Block Kit Tool. It doesn't.

Also, although the documentation for python says you need to urlEncode the JSON-based array, there is no example of using "blocks" in the python sample code, and the description at https://api.slack.com/methods/chat.postMessage#arg_blocks is incorrect.

You can see on line 29 in the SDK test code below that blocks= takes a regular list of dicts, not a string. https://github.com/slackapi/python-slack-sdk/blob/c9dc6aa0907a72c16cf36aa15e7e80031a9fdce2/integration_tests/samples/basic_usage/sending_a_message.py

[kbroughton]

@seratch I've created a gist to reproduce the issue https://gist.github.com/kbroughton/e46edc3f6454c8dc33a09431b5685a6c

[filmaj]

I'm able to reproduce @ateymour's issue. This code:

    client.chat_postMessage(
        channel=context.channel_id,
        text="hi",
        attachments=[{
            "color": "#f2c744",
            #  ignored in this case: "text": "This is a test text message",
            "blocks": [
                {
                    "type": "section",
                    "text": {
                        "type": "mrkdwn",
                        "text": "This is a markdown block"
                    }
                }
            ]
        }]

Yields this message:

Whereas this code:

    client.chat_postMessage(
        channel=context.channel_id,
        text="hi",
        attachments=[{
            "color": "#f2c744",
            "text": "This is a test text message",
            #"blocks": [
            #   {
            #      "type": "section",
            #        "text": {
             #           "type": "mrkdwn",
            #            "text": "This is a markdown block"
            #        }
            #    }
            #]
        }]

Yields:

Finally, uncommenting everything like so:

    client.chat_postMessage(
        channel=context.channel_id,
        text="hi", # can also comment this line out; same result
        attachments=[{
            "color": "#f2c744",
            "text": "This is a test text message",
            "blocks": [
                {
                    "type": "section",
                    "text": {
                        "type": "mrkdwn",
                        "text": "This is a markdown block"
                    }
                }
            ]
        }]

Yields the following error:

The server responded with: {'ok': False, 'error': 'invalid_attachments', 'errors': ['invalid_keys'], 'response_metadata': {'messages': ['[ERROR] invalid_keys']}})

I agree that the documentation around how to use blocks within attachments is lacking and could use some more clarification. Furthermore, the error message "invalid_attachments: invalid_keys" is not super helpful. Which keys are invalid?

I will raise this as a documentation issue internally to see what we could do to improve the usability here.

[filmaj]

Interestingly, the second example in this section of the docs works fine. This example uses a top-level blocks parameter and an attachments parameter that itself contains a blocks property... worth exploring deeper here what is going on.

[github-actions[bot]]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

[github-actions[bot]]

As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number.

[k-nelis]

Exist an solution for case?

[Steinbjarne]

Interestingly, the second example in this section of the docs works fine. This example uses a top-level blocks parameter and an attachments parameter that itself contains a blocks property... worth exploring deeper here what is going on.

Would be nice with a solution on this.