gunnargrosch / failure-lambda Goto Github PK

When setting 'failureMode' to 'exception' the Lambda function returns successfully, an exception occurs but the Lambda function succeeds.

START RequestId: 303ca17f-a63c-44ce-a38e-9236e3db57c2 Version: $LATEST
2020-02-07T14:18:14.839Z	303ca17f-a63c-44ce-a38e-9236e3db57c2	INFO	Injecting exception message: Exception message!
2020-02-07T14:18:14.852Z	303ca17f-a63c-44ce-a38e-9236e3db57c2	INFO	Error: Exception message!
    at Runtime.handler (/var/task/node_modules/failure-lambda/lib/failure.js:31:17)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)END RequestId: 303ca17f-a63c-44ce-a38e-9236e3db57c2
REPORT RequestId: 303ca17f-a63c-44ce-a38e-9236e3db57c2	Duration: 142.89 ms	Billed Duration: 200 ms	Memory Size: 128 MB	Max Memory Used: 96 MB	

I would have expected a thrown exception to cause the Lambda function to fail.

Enabling or disabling experiments using failuremode: denylist is not working as expected. There is either a delay or a refresh of the function container (update, redeploy, new cold start, etc.).

It would be great to be able to simulate failure of a service dependency (access to DynamoDB for example). This could be simulated through manipulation of IAM roles / permissions but it would be great to be able to extend this to other network dependencies (MongoDB connectivity, other microservices, etc).

Would it make sense to configure failure-lambda to simulate the failure of a network dependency through interception of the network calls?

@gunnargrosch

What do you think about an optional feature to cache the SSM config value?

We've ran into some SSM throttling issues while running load tests on our lambdas.

• https://docs.aws.amazon.com/general/latest/gr/ssm.html | GetParameter is 40 requests per second by default

Ideally, we'd like to cache the value for a configurable amount of time.

Thoughts? I don't mind providing a PR to this project or simply forking the project either.

We are getting following error message while trying to deploy a lambda via CF template on AWS after including failure-lambda library.

UPDATE_FAILED: Resource handler returned message: "Unzipped size must be smaller than 262144000 bytes (Service: Lambda, Status Code: 400)

Can you please help?

I would like to ask why the event was changed to the connection in this commit ae590c8f7b73b1eec64ab2460b0987df03d4cddc ?

The current change is quite crucial, while it breaks the logic of usingsocket.bypass(). When we start relying on the connection event, then it's not possible to bypass the mitm hook and continue the origin request, because the check of bypassed flag in mitm is done on the connect event.
mitm.connect

I am looking forward to your response.