When using custom logger, every request input/output is logged as info, not as debug / trace

[joepjoosten]

Describe the bug

When i attach a custom Logger to a clients config, every request sent will log the request and response to the info logger, which will produce a very large log files if the log level is on info. It feels to me that this should be on log level debug or trace.

Example log file entry:

timestamp=2024-05-20T19:28:14.384Z level=INFO fiber=#26995 message="{
\"clientName\": \"SQSClient\",
\"commandName\": \"ReceiveMessageCommand\",
\"input\": {
\"QueueUrl\": \"https://sqs.eu-central-1.amazonaws.com/.....<redacted>",
\"MaxNumberOfMessages\": 1,
\"VisibilityTimeout\": 30,
\"WaitTimeSeconds\": 20
},
\"output\": {},
\"metadata\": {
\"httpStatusCode\": 200,
\"requestId\": \"<redacted>\",
\"attempts\": 1,
\"totalRetryDelay\": 0
}
}"

Possible location of log in code: https://github.com/aws/aws-sdk-js/blob/582b7bf8adc5b1e77c4d3e3f7d2a261cdd47daf5/lib/event_listeners.js#L689C7-L694C8

is the Logger.log function somehow coupled to the Logger.info function in the client?

How to prevent this?

Expected Behavior

Only input/output logging when log level is on debug or trace.

Current Behavior

Input/output logging when log level is on info

Reproduction Steps

import { ListQueuesCommand, SQSClient } from "@aws-sdk/client-sqs";

const client = new SQSClient({
    region: "eu-central-1",
    logger: {
        error: s => console.log(`error: ${JSON.stringify(s)}`),
        warn: s => console.log(`warn: ${JSON.stringify(s)}`),
        info: s => console.log(`info: ${JSON.stringify(s)}`),
        debug: s => console.log(`debug: ${JSON.stringify(s)}`),
        trace: s => console.log(`trace: ${JSON.stringify(s)}`),
    }
})

async function main() {
    await client.send(new ListQueuesCommand());
    console.log('done');
}

main();

Possible Solution

No response

Additional Information/Context

No response

SDK version used

3.576.0

Environment details (OS name and version, etc.)

macos

[joepjoosten]

What do you think about this? Should it be log level info? or something else?

[kuhe]

this is an aws-sdk-js-v3 issue

[aBurmeseDev]

Hi @joepjoosten - thanks for reaching out.

The reason behind input/output logging level being as info vs debug is because info-level logging is used to highlight important pieces that user's looking for whereas debug-level logging is used when user's trying to diagnose an issue for debugging purposes.

To address the log file being large, you can identify if the request log comes from the SDK and it can be filtered out with the implementation of info function to reduce the file size.

Let me know if that helps, John

[joepjoosten]

Thanks for taking your time.

The solution you gave is possible of course, but it still doesn't feel like "high level" enough of an abstraction to simply log the input and output. I know this only occurs when you attach an logger yourself, so most devs won't have this issue.

An example of the log levels in AWS documentation: https://docs.aws.amazon.com/iot/latest/developerguide/configure-logging.html#log-level

These log levels determine the events that are logged and apply to default and resource-specific log levels.

ERROR

Any error that causes an operation to fail.

Logs include ERROR information only.

WARN

Anything that can potentially cause inconsistencies in the system, but might not cause the operation to fail.

Logs include ERROR and WARN information.

INFO

High-level information about the flow of things.

Logs include INFO, ERROR, and WARN information.

DEBUG

Information that might be helpful when debugging a problem.

Logs include DEBUG, INFO, ERROR, and WARN information.

DISABLED

All logging is disabled.

For me it's more debug level information, but if I'm the only one, you can close the ticket.

[aBurmeseDev]

Totally understand your use case here. Unfortunately, we can't make the change at this time. Please refer to the solution mentioned and if you run into any trouble, feel free to reach out again!

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.