Slack app won't continue processing unless I change tabs or trigger another action/event on AWS Lambda without a deferred response

[dsarlo-viso]

I am currently updating our existing slack app to use the new AI App chat features built into slack. Before we were using slash commands. We deploy our slack app as a lambda function in AWS and I have been using the expressReceiver since we use OAuth.

Right now, I am just trying to do the following:

slackApp.event('assistant_thread_started', async ({ event, client, logger }) => {
    try {
        const assistantThread = (event as any).assistant_thread;
        const channel_id: string | undefined = assistantThread?.channel_id;
        const thread_ts: string | undefined = assistantThread?.thread_ts;
        if (!channel_id || !thread_ts) {
            logger.warn('assistant_thread_started missing channel_id or thread_ts');
            return;
        }
        await client.chat.postMessage({
            channel: channel_id,
            thread_ts,
            text: 'How can I assist you?',
        });
    } catch (error) {
        logger.error(error);
    }
});

I was using the Assistant interface and applying that to the slackApp previously but switched to this "lower level" approach to make sure this would work and I run into the same issues.

I am posting here because I am out of ideas. Set up provisioned concurrency and everything and nothing on the AWS/infra side has helped. We did not have these issues when using slash commands as we were using axios to make api calls to send messages to the slack client to the user to avoid this I believe.

When running locally, this works 100% of the time and instantly, but once we deploy the app, opening a new chat with the app does nothing. Once I swap tabs and go back to the chat window, then the message shows up, every time no matter how long I wait.

Same thing seems to happen when actually chatting with the agent as well.

When trying to use setStatus and setTitle to show that the AI is thinking, it doesn't update the chat UI until we change tabs back and forth or send another message. Basically any action that triggers the slack app again.

We are using bolt js 4.4.0

[dsarlo-viso]

Wow. After hours of debugging and attempting things...

I stumbled across an old github issue on here that mentions needing to add processBeforeResponse: true to the ExpressReceiver as well. You cannot just have it specified in the config of the App instance...

The documentation isn't clear as well, since it mentions needing to set processBeforeResponse when using ExpressReceiver but then shows you an example of the AwsLambdaReceiver that sets that property in the App instance and not on the AwsLambdaReceiver.

https://docs.slack.dev/tools/bolt-js/deployments/aws-lambda/#1-prepare-the-app-for-aws-lambda

We should update the documentation to have devs set the processBeforeResponse on the receiver.

[zimeg]

@dsarlo-viso Thank you so much for sharing these details from your debugging session 🙏 ✨

I agree we can improve this page with code samples and a highlighted need for deferred responses more. Updating a related comment in the examples might be useful too. Let's keep this issue open!

bolt-js/examples/deploy-aws-lambda/app.js

Lines 13 to 17 in 9337e06

	// When using the AwsLambdaReceiver, processBeforeResponse can be omitted.
	// If you use other Receivers, such as ExpressReceiver for OAuth flow support
	// then processBeforeResponse: true is required. This option will defer sending back
	// the acknowledgement until after your handler has run to ensure your function
	// isn't terminated early by responding to the HTTP request that triggered it.