Fix Lambda CloudWatch metric recording upon invocation error #9752
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Lambda records a CloudWatch (CW) error metric upon every failed Lambda invocation but LocalStack does not record the error metric anymore since the Lambda invocation loop rework. @steffyP recently added a test for this behavior in #9653 discovered in a Pro sample.
see AWS CW metrics
Changes
Discussion
localstack.services.lambda_.invocation.version_manager.LambdaVersionManager.invoke(i.e., all exceptions exceptStatusErrorException) won't be recorded as errors. For example, exceptions from the Lambda control plane (e.g.,TooManyRequestsException) should be recorded in other metrics (e.g.,Throttles).Background
looks like a bug introduced in the Lambda invocation loop rework: https://github.com/localstack/localstack/pull/8970/files#diff-056f8f1dc9188bf87729941f6be9805c0caf16189dafa882f16fb259676f79daL727
similar to the
record_invocationcase here:https://github.com/localstack/localstack/pull/8970/files#diff-056f8f1dc9188bf87729941f6be9805c0caf16189dafa882f16fb259676f79daR220
This should be fixed in the
version_manager.py::invoke