1

tldr: Is it possible for a connected Lambda codehook to spin down then spin back up (possibly multiple times) before replying to Lex?

Some details first: I have a Lambda function in Java 8 which is connected to an Intent on my Lex chatbot. This is a "Initialization and validation code hook" Lambda, meaning any time my intent is activated, Lex queries my Lambda with the input from the user using the Input Event format specified here: https://docs.aws.amazon.com/lex/latest/dg/lambda-input-response-format.html#using-lambda-response-format. Now the way I've been handling input events and responses is through a function called "handleRequest()", which takes as args an InputStream, OutputStream, and Context. After reading the InputStream and activating appropriate logic, I write to the OutputStream object provided as input to handleRequest (using the response format in the link above) and Lex is happy. This is how things work now, and it has met my needs.

However, now I have a new problem. Part of my Lambda logic now relies on making a request to a third-party web API. After making this request, my Lambda spins down (it stops computing). Eventually, this third party API will make a call to my Lambda with information needed to fulfill my intent, but by this point since I have spun down my Lambda I have lost that OutputStream object which I used to write my response to Lex into.

My question is if there is another way. Is there a way to reply to Lex somehow else using Java 8? Maybe I make a reply to Lex directly from Lambda sometime after Lex calls Lambda and Lambda is ready. Has anyone else ever done this or had experience with a Lambda which needs to spin down before replying to Lex?

Please share any insights.

Peter Wofford
  • 26
  • 2

1 Answers1

2

The old process that you describe was synchronous but now you're migrating it to be async and that means that you'll need to change your design: since the same lambda cannot do both the querying (to the 3rd party) and responding back to Lex, you'll have to create new "players":

  1. once a lambda called the 3rd party, it should persist its data (context) into a persistence storage (DB) and exit
  2. receiving the callback from the 3rd party will have to be done by a different lambda which will look in the DB to get the relevant context and combine it with the data it got from the 3rd party and after composing the result it will have to call Lex (this is not a response anymore!) to update it.

I'm not familiar with Lex so I can't tell you if that's supported by it.

Another option is, to see if instead of getting a callback from the third-party, you can poll for the result. If there's such an option the lambda can run in a loop that sleeps for a few seconds, then polls the 3rd party to get the result, until it does.

Important to note that lambda execution time in AWS is limited (up to 15 minutes) so if it takes longer to the 3rd party to resolve your queries - this solution will not work.

Nir Alfasi
  • 53,191
  • 11
  • 86
  • 129