Fix order of events

[rudpot]

Executing the lambda handler in all cases and only over-writing the error code if a valid parameter result is received means that the function code will be invoked and will falsely report an error instead of not being invoked and reporting a fake error.

aws-lambda-chaos-injection/chaos_lambda.py

Lines 343 to 346 in a6d10af

	if _fault_type == "status_code":
	result = func(*args, **kwargs)
	if isinstance(_chaos_conf.get("error_code"), int):
	_error_code = _chaos_conf.get("error_code")

The simple solution would be to fix the order of operations. The structurally better solution would be to rebuild the whole library with a hooks pattern where the customer could define a list of faults/frequencies to inject before and after function execution.

[adhorn]

@rudpot why would invoking and reporting a fake error be better than invoking and overriding the response?

[rudpot]

As a consumer I would like the freedom to choose whether a fault injection should occur before or after the business logic is executed. Or, more to the point, whether the business logic is invoked at all. Both have value to test different aspects of application resilience.

However, as AWS employee, in a situation where that choice does not exist, I would err on the side of "safe" failures. Executing the business logic but reporting the execution as failed will create an inconsistent state in the application between upstream and downstream components. This creates a much higher bar for application resilience than not executing the business logic and just reporting a failure. The latter might create an inconsistent state but it would be limited to the upstream components and would be transparent.