Slack sends "operation_timeout" when running a command, whether the command fails or succeeds

@linjer Indeed, our documentation can be more detailed to mitigate FaaS users’ confusion. Thanks for the suggestions. Before working on that, let me quickly answer your questions here:

How processBeforeResponse actually impacts user code

When processBeforeResponse is true, as mentioned here, Bolt holds off immediately sending an HTTP response regardless of ack() method call timing. This would be beneficial to prevent your FaaS runtime from being forcibly terminated by its platform.

do we need to ack() at all?

Except Events API patterns (meaning app.event, app.message listeners), your app still needs to perform ack() method call in your listener.

Should we move ack() to the end? Why couldn’t I just move ack() to the end if my process takes < 3s, and do I even need this config in this case?

No, you don’t. When processBeforeResponse is false plus your listener always uses await for async function calls, this way can work as you expect, even on FaaS runtime.

Contrarily, when processBeforeResponse is true, the timing to call ack() method does not matter. Bolt does not send an ack response until the whole listener function execution completes. We believe that this behavior is more predictable for many developers and that’s why we generally recommend using processBeforeResponse: true option for FaaS use cases.

However, as long as you understand how it works, placing await ack() at the end plus disabling processBeforeResponse is totally fine.

What is the relation of unhandledRequestTimeoutMillis to the 3s limit mentioned in many of the threads about FaaS + processBeforeResponse? Is it actually not a hard 3s limit, i.e. the process just needs to complete before unhandledRequestTimeoutMillis which has a default value of 3000ms?

The only way to utilize unhandledRequestTimeoutMillis option would be to set a smaller time period than 3 seconds and customize the user-facing error message rather than the default timeout error by Slack clients. That being said, this is not always useful. For instance, when handing Events API payloads, telling the timeouts to end-users is not so simple. Your app may have to send a DM/channel message (meaning your app needs to call conversations.open, chat.postMessage API, and so on) to the affected user to inform that a timeout situation occurred due to your 3rd party app’s response time.

Can we also change the expected response timeout in the Slack app UI?

No, there is no way to adjust this as of today. Also, we don’t have anything to share for future enhancement so far.

How does AwsLambdaReceiver differ from ExpressReceiver and what does this mean for users of other providers? Does it simply set processBeforeResponse: true as a convenience?

AwsLambdaReceiver is an optimized receiver for AWS Lambda functions. The receiver consists of only necessary code for AWS Lambda functions. It is much simpler and smaller piece of code. Although we haven’t done any performance test with it, AwsLambdaReceiver may perform slightly better in terms of memory footprint and runtime performance. That being said, other built-in receivers run fast enough.

What is AWS specific?

You can easily generate an AWS Lambda compatible handler function from the receiver’s start method as below:

module.exports.handler = async (event, context, callback) => {
  const handler = await awsLambdaReceiver.start();
  return handler(event, context, callback);
}

Refer to https://slack.dev/bolt-js/deployments/aws-lambda for more details. This way should be much handier and more flexible than using ExpressReceiver along with Express app converter: @vendia/serverless-express.

Suggestions to offload heavy processes seem to leave developers who want to use say(…) or respond(…) with result information in the dark - can we somehow reliably pass these to other processes?

Good point. Unfortunately, there is simple way to restore those utility methods in a different AWS Lambda execution (offload processes in your words). If you invoke the offload function as an HTTP triggered function with the same set of request body and headers, you may be able to reuse Bolt’s foundational layer for offload functions.

I hope these answers were helpful to you and future readers!

Some of the issues with timing were unrelated, and caused by the lambda function itself timing out, which was fixed by raising the limit in the config settings there.

The error message still shows up after moving the ack(), removing processBeforeResponse, with and without the unhandled request changes. The function is pretty slow, so I’ll try using asynchronous execution, separate functions for time consuming logic, or running it on EC2 instead.

I’ll update if I notice anything else, but thanks for your help so far!