GGv2: Pinned (long lived) Node.js Lambda Times Out

Yep! That's actually the example I've been working with except that I stripped it back to just run the express web server portion:

// WebServerNode.js

// const ggSdk = require('greengrass-core-sdk')

// const iotClient = new ggSdk.IotData()
const os = require('os')
const express = require('express')

const GROUP_ID = process.env.GROUP_ID
const THING_NAME = process.env.AWS_IOT_THING_NAME
const THING_ARN = process.env.AWS_IOT_THING_ARN
const PORT = process.env.PORT

// const base_topic = THING_NAME + '/web_server_node'
// const log_topic = base_topic + '/log'

// function publishCallback(err, data) {
//     console.log(err);
//     console.log(data);
// }

// This is a handler which does nothing for this example
exports.function_handler = function(event, context) {
    console.log('event: ' + JSON.stringify(event));
    console.log('context: ' + JSON.stringify(context));
};

const app = express()

app.get('/', (req, res) => {
                               res.send('Hello World!')
                               
                               console.log('Hello World request serviced');

                            //   const pubOpt = {
                            //       topic: log_topic,
                            //       payload: JSON.stringify({ message: 'Hello World request serviced' })
                            //   };

                            //   iotClient.publish(pubOpt, publishCallback);
                           }
       )

app.listen(PORT, () => console.log(`Example app listening on port ${PORT}!`))

I seem to have found a "solution" by setting the statusTimeoutInSeconds value to the largest 32-bit signed integer (2147483645). This results in an error in the Lambda log on the GG core:

2022-06-09T13:56:33.269Z [ERROR] (pool-2-thread-70) WebServerNode: (node:2398) TimeoutOverflowWarning: 2147483645000 does not fit into a 32-bit signed integer.. {serviceInstance=0, serviceName=WebServerNode, currentState=RUNNING}
2022-06-09T13:56:33.272Z [ERROR] (pool-2-thread-70) WebServerNode: Timeout duration was set to 1.. {serviceInstance=0, serviceName=WebServerNode, currentState=RUNNING}

Now, the Lambda runs fine and continues to handle incoming requests via express as expected. For reference, this is the configuration I'm using for the GGv2 component:

{
  "lambdaExecutionParameters": {
    "EnvironmentVariables": {
      "PORT": "8001"
    }
  },
  "containerParams": {
    "memorySize": 16000,
    "mountROSysfs": false,
    "volumes": {},
    "devices": {}
  },
  "containerMode": "NoContainer",
  "timeoutInSeconds": 60,
  "maxInstancesCount": 100,
  "inputPayloadEncodingType": "json",
  "maxQueueSize": 1000,
  "pinned": true,
  "maxIdleTimeInSeconds": 60,
  "statusTimeoutInSeconds": 2147483645,
  "pubsubTopics": {
    "0": {
      "topic": "*",
      "type": "IOT_CORE"
    }
  }
}

One interesting note is that the error says "TimeoutOverflowWarning: 2147483645000 does not fit into a 32-bit signed integer"; however, the value in the configuration is 2147483645. My guess is the Lambda runtime is multiplying this value by 1000 and using it as milliseconds for some call to setTimeout()/setInterval(), and the backup value of 1 somehow fixes the issue I'm seeing.

Setting the statusTimeoutInSeconds value to 2147483 (a very large, valid number for setTimeout()/setInterval()) works as well, but would seem to result in just delaying this issue and the Lambda being killed after 2,147,483 seconds (a little less than 25 days) - not ideal.

For the sake of completeness, I also tried a statusTimeoutInSeconds value of 0 (I had to override the setting in the deployment configuration since the AWS IoT UI Console does not allow a value less than 30 when creating a Lambda component). This also does NOT work and results in the timeout firing immediately (crashing the Lambda).

Hi. Have you seen this?

https://docs.aws.amazon.com/greengrass/v2/developerguide/run-lambda-functions.html#lambda-lifecycle

Long-lived functions have timeouts that are associated with each invocation of their handler. If you want to invoke code that runs indefinitely, you must start it outside of the handler.

Which example did you follow? This is a pinned example, and invokes the code outside of the handler: https://github.com/aws-samples/aws-greengrass-lambda-functions/blob/master/functions/WebServerNode/WebServerNode.js

Configuration here: https://github.com/aws-samples/aws-greengrass-lambda-functions/blob/master/functions/WebServerNode/function.conf

I hope that helps.