The trigger_id expiring in 3 seconds.

[mansoorpnkr]

(Describe your issue and goal here)

We configured the slack_bolt application using Lambda and API gateway in the AWS cloud by using it as a container. As per the document https://api.slack.com/interactivity/handling#modal_responses, the Triggers expire in three seconds. So, Sometimes, after a while without any shortcut being executed, there is an error when performing a shortcut, where the trigger id is expired. The logs in the Lambda logs are as below.

The server responded with: {'ok': False, 'error': 'invalid_arguments', 'response_metadata': {'messages': ['[ERROR]trigger_idexpired [json-pointer:/trigger_id]']}})

Is there any way we can increase the trigger_id expiry time?

This issue is not reproducible testing locally. Only when we use the API Gateway endpoint.

pip freeze | grep slack
python --version
sw_vers && uname -v # or `ver`

The slack_bolt version

pip3.8 freeze | grep slack

slack-bolt==1.5.0 slack-sdk==3.7.0 slackclient==2.9.3

Python runtime version

(Paste the output of python --version)

Python 3.8.10

OS info

AWS Lamda function

[filmaj]

Is there any way we can increase the trigger_id expiry time?

There is no way to increase the 3 second timeout.

We configured the slack_bolt application using Lambda and API gateway in the AWS cloud by using it as a container. As per the document https://api.slack.com/interactivity/handling#modal_responses, the Triggers expire in three seconds. So, Sometimes, after a while without any shortcut being executed, there is an error when performing a shortcut, where the trigger id is expired.

It sounds to me like maybe AWS Lambda cold start could be making your application respond slowly after some amount of time of inactivity (here is a great blog post on some details around how and when cold starts happen in AWS Lambda). Start times within Lambda depend on your code, of course, but also on the runtime. From your original post, it sounds like you might be using a custom runtime / container? If so, that could also factor into how long the cold start time is. That said, the default AWS Lambda runtimes are extremely fast, with typical Python runtime cold start times under 500ms in most cases and generally even less than that if you can keep your Lambda code size under 5MB.

Do you know what the cold start initialization time using your code / runtime container is like? Perhaps it may be worth looking into your CloudWatch API Gateway metrics to see what the latency for your HTTP responses look like? You could check by looking at CloudWatch -> Metrics -> All Metrics -> API Gateway -> Select your API Gateway -> Latency. I would check if there are any abnormal latency patterns for your application. Perhaps look for big spikes in latency after a period of inactivity - that could indicate a long cold start time that could be causing the timeouts. Similarly, in CloudWatch metrics you can look at the AWS Lambda "Duration" metric to isolate the execution duration down to individual Lambdas (under CloudWatch -> Metrics -> All Metrics -> Lambda -> Select a specific function or choose "Across All Functions" -> Duration).

Some things to try:

• Monitor your application's HTTP response latency to understand the frequency of the problem, using e.g. AWS CloudWatch Metrics, particularly the API Gateway metrics. APIG itself is very fast - if anything, its integration with AWS Lambda (and thus your application code and/or runtime container if applicable). Lambda itself can be monitored granularly as I mentioned above.
• If you are using a custom runtime, ensure it boots up as quick as possible. Every millisecond counts when you only have 3,000 of them!
• If you are running asynchronous workloads within your response Lambda, consider offloading from the HTTP response Lambda to an asynchronous worker using e.g. AWS SNS or AWS SQS. This is a powerful pattern in AWS Lambda that also helps modularize your code and ensure your HTTP responses remain fast.

Hope that helps!

[mansoorpnkr]

Thank you for the update @filmaj

I will go through your recommendations.

[filmaj]

Sounds good.

If there are no actionable next steps in this issue for the SDK, could you please consider closing this issue? Thanks!

[smoneta]

I worked around this using a 'buffer' view... so, as soon the payload comes in, I ack and open a view (with a nice pic that say LOADING) and I save the view ID... then I can do whatever I need and then simply UPDATE the view using the id. works like a charm.

[mansoorpnkr]

Thank you for the update @smoneta .

@filmaj I will close the issue now and if I need any further help, I will open a new issue later.