Bolt-js: An "invalid_attachments" error is thrown when blocks are included within a MessageAttachment object

[victoria-miltcheva]

Description

I'm calling client.chat.postMessage and passing in an array of message attachments. Without setting the blocks property for one of the elements of the array, the message posts as expected and includes the attachments.

However, if I set the blocks property in one of these attachment elements, an "invalid_attachments" error is thrown.

The full stack trace can be found at the bottom of this issue.

What type of issue is this? (place an x in one of the [ ])

• [x] bug
• [ ] enhancement (feature request)
• [ ] question
• [ ] documentation related
• [ ] example code related
• [ ] testing related
• [ ] discussion

Requirements (place an x in each of the [ ])

• [x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
• [x] I've read and agree to the Code of Conduct.
• [x] I've searched for any related issues and avoided creating a duplicate issue.

---

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

package version:
@slack/bolt 2.5.0

node version:
13.10.1

OS version(s):
macOS Mojave Version 10.14.6

Steps to reproduce:

1. Here's an example code block which uses placeholder values:

const testSectionBlock: SectionBlock = {
    type: "section",
    text: {
        type: "mrkdwn",
        text: "Section block text"
    }
};

const blocks: KnownBlock[] = [testSectionBlock];

const attachments: MessageAttachment[] = [
    {
        text: "Message attachment text",
        callback_id: "test_callback_id",
        color: "#88D8B0",
        blocks // if you don't include this argument, it works
    }
];

const response: any = await client.chat.postMessage({
    text: "Outer text"
    attachments,
    channel,
    token,
});

Expected result:

What you expected to happen

Here's a screenshot of how the message looks without the blocks included:

It should be able to include the blocks within the message attachments.

Actual result:

What actually happened

Error: An API error occurred: invalid_attachments

^ Prevents the message from being posted

Attachments:

Logs, screenshots, screencast, sample project, funny gif, etc.

Notes:

• In the Slack Node SDK index file, MessageAttachment can include an optional blocks property.
• There's documentation which shows an example of blocks being included in an attachments field.
  
• In the Slack Java SDK, there are test cases asserting that "invalid_blocks" should be thrown. Although in the linked issue, it's stated that blocks within attachments should be supported.

Logs:

Error: An API error occurred: invalid_attachments
    at Object.platformErrorFromResult (/<REDACTED>/node_modules/@slack/web-api/dist/errors.js:51:33)
    at WebClient.apiCall (/<REDACTED>/node_modules/@slack/web-api/dist/WebClient.js:156:28)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async /<REDACTED>.js:112:30
    at async Array.<anonymous> (<REDACTED>/node_modules/@slack/bolt/dist/middleware/builtin.js:203:9)
    at async Array.exports.onlyCommands <REDACTED>/node_modules/@slack/bolt/dist/middleware/builtin.js:41:5) {
  code: 'slack_webapi_platform_error',
  data: {
    ok: false,
    error: 'invalid_attachments',
    response_metadata: {
      messages: [ '[ERROR] invalid_keys' ],
      scopes: [
        'channels:history',
        'channels:join',
        'chat:write',
        'commands',
        'users:read',
        'users:read.email',
        'channels:read',
        'im:write',
        'channels:manage',
        'groups:write',
        'mpim:write'
      ],
      acceptedScopes: [ 'chat:write' ]
    }
  }
}

[victoria-miltcheva]

I tested this with the chat.postMessage API directly and it did post a message in my channel but the attachments weren't included.

Message

Arguments
text: Outer text
attachments:

[
    {
      "blocks": [
        {
            type: "section",
            text: {
                type: "mrkdwn",
                text: "Section block text"
            }
        }
      ]
    }
]

Posted message:

[mwbrooks]

Hey @victoria-miltcheva,

I just spent some time testing it with chat.postMessage and had the same result as you.

This appears to be an issue with the Slack API and not directly with the Bolt Framework. I've found that when text and callback_id are removed, then the blocks are displayed correctly. However, this probably isn't ideal for you:

{
    "channel": "D019KTNNK8B",
    "text": "Outer text",
    "attachments": [
      {
          "color": "#88D8B0",
          "blocks": [
            {
              "type": "section",
              "text": {
                  "type": "mrkdwn",
                  "text": "Section block text"
              }
            }
          ]
      }
    ]
}

Attachments are a legacy feature and there may have been a bug introduced. I'll report this issue to the Slack API team, but I can't promise that it'll be resolved because it's a legacy feature.

Can you use the blocks parameter instead of attachments for chat.postMessage? This will allow you to use the modern Block Kit approach. Since you're already using blocks you should be able to display the same UI.

[victoria-miltcheva]

Hi @mwbrooks,

Thanks for testing this out and relaying the bug to the Slack API team! And nice, the blocks are displayed correctly for me as well when I exclude text/callback_id.

Can you use the blocks parameter instead of attachments for chat.postMessage?

Yeah, this does work.

I understand that message attachments are a legacy feature and we should be using Block Kit blocks over it. The reason I'm using attachments is so that I can use the color field for different sections of the message.

I'm rewriting an older app which uses theslapp package and the message attachment colors represent different statuses, so it'd be preferable to retain that. I haven't found a way to set a color for different sections of the message using Block Kit. For everything else though, I'll definitely use Block Kit blocks.

[mwbrooks]

I understand that message attachments are a legacy feature and we should be using Block Kit blocks over it. The reason I'm using attachments is so that I can use the color field for different sections of the message.

Haha, I kinda suspected that color was your reason for using attachments. I'm guilty of using attachments for the same reason. I'll submit a feature request to add your +1 to supporting color in Block Kit.

Question:

Does removing text / callback_id solve your issue? You'll lose access to callback_id (I assume for a legacy button or menu) but you could likely take advantage of action_id in blocks.

[victoria-miltcheva]

Does removing text / callback_id solve your issue? You'll lose access to callback_id (I assume for a legacy button or menu) but you could likely take advantage of action_id in blocks.

Yes, removing these fields solved my issue. I was also able to use action_id in blocks for the button and my action middleware was triggered when it was clicked.

Thanks again for your help and for submitting a color feature request for Block Kit 👍 .

[mwbrooks]

You're very welcome @victoria-miltcheva! I'm going to close this issue since there's nothing more than we can do with the client-side SDK.