Bolt-js: Unable to ack with errors

[SpencerKaiser]

Description

The example for how to respond to a dialog with errors will not compile in typescript.

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

• [x] bug
• [ ] enhancement (feature request)
• [ ] question
• [ ] documentation 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

When trying to respond to a dialog submission with validation errors, the ack method will not accept an object with error values.

Steps to reproduce:

1. Create dialog and submit via Slack
2. Follow guide in readme using this ack:

ack({
  errors: [{
    name: 'ticketId',
    error: 'This value must begin with CODE',
  }],
});

1. The following error will display:

(property) error: string
Argument of type '{ errors: { name: string; error: string; }[]; }' is not assignable to parameter of type 'Pick<ChatPostMessageArguments, "text" | "as_user" | "attachments" | "blocks" | "icon_emoji" | "icon_url" | "link_names" | "mrkdwn" | "parse" | "reply_broadcast" | "thread_ts" | "unfurl_links" | "unfurl_media" | "username" | "token"> & { ...; } & DialogValidation & void'.
  Property 'text' is missing in type '{ errors: { name: string; error: string; }[]; }' but required in type 'Pick<ChatPostMessageArguments, "text" | "as_user" | "attachments" | "blocks" | "icon_emoji" | "icon_url" | "link_names" | "mrkdwn" | "parse" | "reply_broadcast" | "thread_ts" | "unfurl_links" | "unfurl_media" | "username" | "token">'.t

Expected result:

ack should accept an errors response object

Actual result:

Compilation error.

Workaround

Credit to @seratch!

import { App, DialogSubmitAction } from '@slack/bolt';

// <DialogSubmitAction> here is necessary at this point
app.action<DialogSubmitAction>({callback_id: 'CALLBACK_ID'}, ({ ack }) => {
    ack({
        errors: [{
            "name": "email_address",
            "error": "Sorry, this isn’t a valid email"
        }]
    });
});

[shaydewael]

I wasn't able to reproduce this. The error seems kind of weird because it reads like it's not recognizing the dialog as a DialogSubmitAction. Do you have the entire action() method you're using to send these errors?

Here's the code I have that seems to be working for me, but the ack() is nearly identical to your's so I'm not sure it's going to be helpful:

app.action({ callback_id: 'YOUR_CALLBACK_ID' }, ({ ack }) => {
  ack({
    errors: [{
      name: 'loc_origin',
      error: 'ugh please work',
    }]
  });
});

[SpencerKaiser]

@shanedewael maybe y’all fixed it with a recent update? I can try again later and see if I’m still getting the same error.

[shaydewael]

Hmm maybe something was touched when we were implementing support for Block Kit in modals but I didn't think that code had been touched for a while. If you try again later and are able to reproduce, let me know and I can dig into it further.

[SpencerKaiser]

@shanedewael Just retested after running npm update @slack/bolt and got the same outcome:

[build:watch] src/Commands/sev.ts:48:9 - error TS2345: Argument of type '{ errors: { name: string; error: string; }[]; }' is not assignable to parameter of type 'Pick<ChatPostMessageArguments, "text" | "as_user" | "attachments" | "blocks" | "icon_emoji" | "icon_url" | "link_names" | "mrkdwn" | "parse" | "reply_broadcast" | "thread_ts" | "unfurl_links" | "unfurl_media" | "username" | "token"> & { ...; } & DialogValidation & void'.
[build:watch]   Property 'text' is missing in type '{ errors: { name: string; error: string; }[]; }' but required in type 'Pick<ChatPostMessageArguments, "text" | "as_user" | "attachments" | "blocks" | "icon_emoji" | "icon_url" | "link_names" | "mrkdwn" | "parse" | "reply_broadcast" | "thread_ts" | "unfurl_links" | "unfurl_media" | "username" | "token">'.
[build:watch] 
[build:watch]  48     ack({
[build:watch]             ~
[build:watch]  49       errors: [{
[build:watch]     ~~~~~~~~~~~~~~~~
[build:watch] ... 
[build:watch]  52       }]
[build:watch]     ~~~~~~~~
[build:watch]  53     });

[shaydewael]

That's odd to me. Do you mind sharing the Bolt code you're using to ack() to dialogs? I'll try to use that code to reproduce it.

[seratch]

As pointed out here, the code in the document seems to be not working with TypeScript (to be precise, TS transpiration fails). I haven't checked the behavior with all the past versions, but at least it doesn't successfully transpire with either 1.0.0 or 1.3.0.

A workaround to address this issue would be to explicitly determine the SlackAction type to be used by having a type parameter as below:

import { App, DialogSubmitAction } from '@slack/bolt';

// <DialogSubmitAction> here is necessary at this point
app.action<DialogSubmitAction>({callback_id: 'CALLBACK_ID'}, ({ ack }) => {
    ack({
        errors: [{
            "name": "email_address",
            "error": "Sorry, this isn’t a valid email"
        }]
    });
});

[SpencerKaiser]

@shanedewael

app.ts
This is a singleton Bolt app that is created on app start and relevant actions/commands are started and with that app.

import { App, LogLevel } from '@slack/bolt';

// Workaround until this issue is closed: https://github.com/slackapi/bolt/issues/250
// TODO: Uninstall @slack/web-api dependency when this is fixed
import { WebClient } from '@slack/web-api';

import commands from './Commands';

if (!process.env.SLACK_SIGNING_SECRET || !process.env.SLACK_BOT_TOKEN) {
  throw new Error('SLACK_SIGNING_SECRET and SLACK_BOT_TOKEN are required environment variables');
}

const app = new App({
  signingSecret: process.env.SLACK_SIGNING_SECRET,
  token: process.env.SLACK_BOT_TOKEN,
  logLevel: process.env.NODE_ENV === 'development' ? LogLevel.DEBUG : LogLevel.INFO,
});

// Initialize the WebClient for future use
app.client = new WebClient(process.env.SLACK_BOT_TOKEN);

// Register routes
commands(app);

export default app;

Commands/index.ts
This file contains a list of all commands listeners that should be started when the app does. It accepts

import { App } from '@slack/bolt';
import someCommand from './someCommand';
import logger from '../logger';

export default function register(app: App): void {
  logger.info('Registering slash command listeners');
  someCommand(app);
}

someCommand.ts
This is the file that registers itself to handle the slash command an responds with a dialogue. The dialogue triggers an action using callbackId. This file is shortened to abstract some of the more sensitive stuff and I've also removed irrelevant imports. If you have a question about something that's missing, let me know!

import { callbackId, dialog } from '../Blocks/sevDialogBlocks';
import { App, DialogSubmitAction } from '@slack/bolt';

export default function register(app: App): void {
  app.command(slashCommand, async ({
      command, ack, context, respond,
    }) => {
      // Acknowledge the request so Slack doesn't get angry
      ack();
      await app.client.dialog.open({
        token: context.botToken,
        trigger_id: command.trigger_id,
        dialog,
      });
  });

  app.action({ callback_id: callbackId }, async ({ ack, action, body }) => {
    ack({
    errors: [{
      name: 'loc_origin',
      error: 'ugh please work',
    }]
  });
});

[shaydewael]

I'm able to reproduce this one now as well. I think @seratch's use of Generics is the best solution for this right now as well.

[SpencerKaiser]

Just updated the description of the issue with the workaround provided by @seratch in case others find this and have the same problem.

[shaydewael]

Thanks for doing that, I'm going to close this issue out for now.

[SpencerKaiser]

Well is that intended behavior? I feel like without an update to the docs, this shouldn’t be closed.

[shaydewael]

@SpencerKaiser Hmmm that's a fair point. I'm not sure where this would go into the documentation since we're primarily highlighting modals as the preferred way to perform this kind of behavior rather than dialogs. I opened #277 (and referenced this issue) since this problem is not just limited to dialogs.

[SpencerKaiser]

I was today years old when I found out that modals exist....... But that’s totally fair, as long as the docs have some info to help those using the (apparently) old school stuff, I’m happy.

[shaydewael]

Modals were just released released last week so you aren't too behind 😜