Consistent ERROR Messages in Lambda Function Logs

[meraj-kashi]

Background

After upgrading to the latest version (v0.7.0), the Lambda function generates ERROR messages in the output logs. While the Kosli commands run successfully, these ERROR messages still appear in the logs:

2025-01-02T10:44:40.507Z | START RequestId: 7b3843cb-acaf-4a67-8ced-1d94677c31cc Version: $LATEST
-- | --
  | 2025-01-02T10:44:42.484Z | [INFO] 2025-01-02T10:44:42.484Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc Command: kosli snapshot lambda sandbox-a01750-dev-lambda --exclude-regex "((nt\-(los\|devex\-kosli\|wafr))\|aws\-controltower).*" --debug
  | 2025-01-02T10:44:42.484Z | [INFO] 2025-01-02T10:44:42.484Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc [debug] processing config file [kosli] [debug] config file [kosli] not found. Skipping. [debug] request made to https://app.kosli.com/api/v2/environments/Norsk-Tipping/sandbox-a01750-dev-lambda/report/lambda and got status 200 1 lambda functions were reported to environment sandbox-a01750-dev-lambda
  | 2025-01-02T10:44:42.484Z | [INFO] 2025-01-02T10:44:42.484Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc Heeeeeeer!
  | 2025-01-02T10:44:42.484Z | [ERROR] 2025-01-02T10:44:42.484Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc
  | 2025-01-02T10:44:44.096Z | [INFO] 2025-01-02T10:44:44.096Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc Command: kosli snapshot s3 sandbox-a01750-dev-s3 --bucket nt-186558567702-infra-state --debug
  | 2025-01-02T10:44:44.096Z | [INFO] 2025-01-02T10:44:44.096Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc [debug] processing config file [kosli] [debug] config file [kosli] not found. Skipping. [debug] downloaded %!(EXTRA string=/tmp/bucketContent797109799/create-s3/terraform.tfstate, int64=5615, string=bytes) [debug] request made to https://app.kosli.com/api/v2/environments/Norsk-Tipping/sandbox-a01750-dev-s3/report/S3 and got status 200 bucket nt-186558567702-infra-state was reported to environment sandbox-a01750-dev-s3
  | 2025-01-02T10:44:44.133Z | [INFO] 2025-01-02T10:44:44.132Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc Heeeeeeer!
  | 2025-01-02T10:44:44.133Z | [ERROR] 2025-01-02T10:44:44.133Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc
  | 2025-01-02T10:44:44.134Z | END RequestId: 7b3843cb-acaf-4a67-8ced-1d94677c31cc

Details

To debug the issue, additional logging was added to the Python script, and it was determined that the following logger statement is causing the ERROR messages in the output:

try:
            result = subprocess.run(
                split_kosli_command,
                env=env,
                stdout=subprocess.PIPE,
                stderr=subprocess.PIPE
            )

            # Log stdout and stderr
            logger.info(f"Command: {kosli_command}")
            logger.info(result.stdout.decode('utf-8'))
            logger.info("Heeeeeeer!")
            logger.error(result.stderr.decode('utf-8'))

Our debugging revealed that result.stderr.decode('utf-8') is an empty string, but the logger still prints an empty string as ERROR:

025-01-02T10:44:44.133Z[ERROR]	2025-01-02T10:44:44.133Z	7b3843cb-acaf-4a67-8ced-1d94677c31cc | [ERROR] 2025-01-02T10:44:44.133Z 7b3843cb-acaf-4a67-8ced-1d94677c31cc
-- | --

Solution

The following modification is suggested to resolve the issue:

if len(result.stderr.decode('utf-8')) > 0:
                logger.error(result.stderr.decode('utf-8'))