Connection timing out on aws lambda

I am trying to connect to a postgres db from an aws lambda function using the below code

var dbConfig = { host: {endpoint}, user: {dbuser}, database: {dbname}, password: {password}, port: {port} };

var pg = require('pg');
var client = new pg.Client(dbConfig);

exports.handler = function(event, context, callback) {
  client.connect(function (err) {
      client.end();
      context.succeed(context);
  });
};

If I run this via node locally it works fine and returns within a second or two. In lambda it times out when allotted up to 60 seconds

the lambda timeout error message is

{
  "errorMessage": "2016-12-12T17:18:18.617Z f8406e80-c08e-11e6-a0d3-8bc89c563312 Task timed out after 60.00 seconds"
}

The db I am trying to get to is on amazon rds and I am using the endpoint they provided me as the host on config.

Any thoughts on why this might be failing to connect?

EDIT: I upped the lambda execute time to 3 mins.

It finally failed after 128 seconds with:

{
  "errorMessage": "connect ETIMEDOUT 35.165.66.116:5432",
  "errorType": "Error",
  "stackTrace": [
    "Object.exports._errnoException (util.js:870:11)",
    "exports._exceptionWithHostPort (util.js:893:20)",
    "TCPConnectWrap.afterConnect [as oncomplete] (net.js:1062:14)"
  ]
}

[hassankhan]

@vitaly-t Actually it is relevant to the library, and it’s getting a bit annoying hearing that it isn’t. All Node Postgres libraries assume that they will be running on long-lived processes, whereas on Lambda that is explicitly NOT the case.

@Andrew-Max You’re having this problem because the connection to PGP doesn’t get closed, and you will have to do it yourself:

var pgp = require('pgp')();

pgp.any(query)
  .then((response) => {
    pgp.end();
    return response;
  })
  .catch((error) => {
    pgp.end();
    throw error;
  });

Sorry, I don’t mean to be rude, its just that your package is one of the few libraries of decent quality on NPM, and it was super frustrating because it worked in a dev environment but not on Lambda.

[joaojeronimo]

So, I just ran into this and my understanding is that even though on your lambda you get to call the final callback and expect it to respond, some custom code on the lambda implementation is checking if there are any handlers (like these open database connections) in the event loop before assuming your function is “done”.

With the context object passed into the handler function, setting context.callbackWaitsForEmptyEventLoop = false makes everything behave as expected for me. The pool is left on the top scope with open connections and the functions “finish”.