Hello! I'm getting this error as well. I expressly `ack` the slash command right at the beginning of the handler.

[asontha]

Hello! I'm getting this error as well. I expressly ack the slash command right at the beginning of the handler.

// The /ask command entry point.
app.command('/ask', async ({ command, ack, client, logger }) => {

  // Acknowledge shortcut request
  await ack();

Originally posted by @asontha in https://github.com/slackapi/bolt-js/issues/1435#issuecomment-1406819093

[mwbrooks]

Hi @asontha 👋🏻 Thanks for reaching out!

The operation_timeout error is typically returned if the app hasn't acknowledged the slash command request after 3 seconds. Since you're correctly using await ack();, I think you should double-check that your app is receiving the slash command request.

Can you try to add a log message before your await ack(); to confirm that the slash command request is hitting your command function?

[asontha]

I am receiving the slash command as my app is replying as expected to the slash command (look at app message posted before the Slackbot error). The behavior is to immediately reply to the command saying that we'll get the answer, and then replying with the answer as a threaded response.

[asontha]

Here's the flow of /ask

User: /ask <QUESTION> BOT: @User asked: <QUESTION> Let me get you the answer for that! I'll reply to this message :smile: BOT (in thread): <ANSWER>

[asontha]

Here is proof that Slack is not waiting 3 seconds for timeout

[asontha]

Here's how I've configured my receiver

// Initialize your custom receiver
const awsLambdaReceiver = new AwsLambdaReceiver({
  signingSecret: process.env.SLACK_SIGNING_SECRET
});

// Initializes your app with your bot token and signing secret
const app = new App({
  token: process.env.SLACK_BOT_TOKEN,
  receiver: awsLambdaReceiver
});

[asontha]

Another example

[seratch]

This behavior can happen when lambda runtime initialization + your listener takes more than 3 seconds. The say() method call and whatever you do in the function can be successful like you observed. However, ack() can fail as the response is sent at the end.

[asontha]

So then if you guys are pushing everyone to use AWS Lambda for deployment but the deployment platform itself can't support it, doesn't it make sense to increase the timeout value to something more reasonable?

[seratch]

@asontha I do understand your frustration on this and we hear you. This seems to be an issue on our documentation side. The getting started guide and other resources should clearly mention the things developers need to be aware of.

As for utilizing AWS Lambda for Slack apps, we believe that the platform is a great option to run those apps in terms of const efficiency and easiness of operations. I myself run many of my personal Slack apps on AWS Lambda. So, it's still recommended but our documents should be improved. Sorry about the confusion you encountered.

I believe that everything is clear (I know the cause is not great for you, though). If you have further questions on this, please feel free to write in. Otherwise, let us close this issue now.

[asontha]

Given this problem is such a massive and reoccurring one, could you guys create a fully fleshed out example of how the solution proposed here would work?

https://github.com/slackapi/bolt-js/issues/914#issuecomment-870079306

[seratch]

Thanks for the suggestion! I've created a new issue for it: https://github.com/slackapi/bolt-js/issues/1728 Let us close this issue now but please feel free to write in whenever you have more to ask.

[Timendainum]

This is not a documentation issue, the length of the timeout is too short. Slack fix this, something is broken on your side.

I get my response back BEFORE your timeout error gets here.

Please fix this.

[acerbisgianluca]

Hi @seratch, thanks for the clarification. Just to be sure, if await ack() is the first call of an handler, the response will still be sent back to Slack when all the other work inside the handler is done, is it correct? What is the recommended solution if the work between await ack() and the end of the handler takes more than 3 seconds?

PS: I'm talking about AWS Lambda

[filmaj]

@Timendainum this is an intentional design decision. The timeout is short so that the user experience within the Slack client is relatively responsive to Slack client user interactivity.

@acerbisgianluca since the HTTP request from Slack is tied to the lifecycle of the AWS Lambda execution, immediately responding to the HTTP request would effectively terminate the Lambda. Therefore, the acknowledgement to the request from Slack is done as a final step in the Lambda execution. This is limitation of HTTP request integrations with AWS Lambda. However, there are many well-documented ways to work around this limitation, and in fact, make your application more resilient as a result. I would recommend to employ event-driven programming best practices, which are a necessity in a cloud environment and particularly in a function-as-as-service architecture. I highly suggest familiarizing yourself with techniques such as:

• publish/subscribe pattern using Amazon SNS: have your bolt handler publish data asynchronously to an SNS topic, and have another lambda subscribe to events from this topic. This is a relatively simple pattern that allows you to decouple longer-running tasks from the Slack HTTP request. Perhaps you need to do data analysis on an incoming Slack message event, or save data to a database, or do any other task that may take longer than 3 seconds. An easy solution is to summarize the task and offload it to another system for processing. This offloading, especially with SNS, is cheap: it doesn't cost much nor does it consume much time to publish to a topic. Amazon has an example of this pattern described. You can use the AWS JS SDK to publish messages to an SNS topic from your bolt handler, and then read the linked documentation to see how to set up a separate lambda to subscribe to messages arriving in the SNS topic.
• queue pattern using Amazon SQS: offload longer-running tasks to an SQS queue, from which you can consume in more sophisticated ways. Perhaps the order of work being offloaded matters. Or perhaps you need to carefully throttle how much of this offloaded work is being done at one time. Amazon SQS can give you these options. Amazon provides documentation on how to integrate Lambda with SQS. Similarly to the above point, you can use the AWS JS SDK to send a message to a queue, and set up a separate lambda, perhaps on a schedule via AWS EventBridge, to poll the queue and pull messages from it.

SNS is generally sufficient for most use cases. Hope this helps!

[acerbisgianluca]

Hey @filmaj, thanks for the detailed reply! I will start exploring the first solution.