fix: extend connection timeout

[blimmer]

Fixes #7

Agree with @moltar - the timeout is very very low and can cause timeout exceptions that could be avoided by just bumping the time.

Since the lambda has 300 seconds to run, a maximum of 30 seconds to connect seems reasonable.

[berenddeboer]

Apologies, only saw this now. The problem I have with this is if the database is not accessible, it'll wait 30seconds. Also 2s seems pretty reasonable for a database? I would find it odd it cannot connect that quickly. I think I rather have it as an option if this is a problem for people.

[blimmer]

The problem is with the initial creation of the database. I can't use this construct because it does not wait long enough for the database to be live, then fails the whole stack.

Perhaps it needs to have additional CFN dependencies?

[berenddeboer]

Ah, so not with resume right? It depends on the rds construct. So is this a v2 serverless? Happy to support this a bit better, but possibly via an option. So if you can help me with the exact conditions? Then I can see if I can get it right or even repeat it.

[blimmer]

I tried using this pacakge with several standard RDS Aurora Postgres clusters, only to have them rolled back because of timeouts from this custom resource.

I think you could reproduce this issue on just a standard rds aurora cluster, because they can take quite a while (~10 minutes) to spin up.

[stephanpelikan]

I have the same issue: I created a serverless PostgreSql which has to auto-pause after 5 mins: Current capacity: 0 capacity units.

Next I extended the stack to create a database but it fails due to timeout.

Regarding timeout: Even deleting the cluster took 1516 seconds. All the time the stack was waiting for the cluster to wake up and receive the 'delete' command. During this period in AWS console the cluster was still active and zero capacity.