Amazon Lex Timing out in 30 seconds on Lambda Full

2019-08-17 23:44发布

问题:

I have a lambda function which is tied to some external automation via a webservice. It takes about 45 seconds for the task to be completed.

I have already updated the time limitation for the lambda call to 2 mins and when I am testing it works fine.

However, when I am using the text bot in Amazon Lex I get the following message:

An error has occurred: Invalid Bot Configuration: Lambda request did not complete within permissible time (30 seconds).

Anyone know how to increase the Lex Bot Configuration to give my lambda script up to at least 1 minute ?

Thanks

回答1:

At the moment this limit can't be modified as it is defined that AWS Lex will throw a 424 - DependencyFailedException if:

One of the dependencies, such as AWS Lambda or Amazon Polly, threw an exception. For example,

  • If Amazon Lex does not have sufficient permissions to call a Lambda function.
  • If a Lambda function takes longer than 30 seconds to execute.
  • If a fulfillment Lambda function returns a Delegate dialog action without removing any slot values.

Source: AWS Lex docs.



回答2:

Can you elaborate more on what you are trying to achieve here? Philosophically a bot should be responsive and hence Lex understandably put such a time limit on the lambda call. I would recommend to model the bot in a way that end user probes the bot for update (which is like polling from the ned user for the response being looked here). In the lambda the request processing should happen asynchronously. For example when the lambda gets a request then:

  • you can create a UUID for the request and process the request asynchronously (put the request on a SQS which another lambda picks and process r something like that).
  • return the UUID to the end user saying " is the request id. Please check the status of this job few seconds.".
  • End user will keep checking about the result of the request saying "whats the status of ". For such and utterance you can have another intent which would trigger lambda to check for the response. In the meanwhile the response of the processing being performed in step 1 could be posted to S3 or put in a database (using UUID as identifier of that data). This current lambda could probe S3 or database to get the result and return it.