Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aws-lambda: logRetention deprecation messages for Provider or CustomResource (most likely) #28806

Closed
holomekc opened this issue Jan 22, 2024 · 4 comments · Fixed by #28783
Closed
Labels
@aws-cdk/aws-logs Related to Amazon CloudWatch Logs bug This issue is a bug. p1

Comments

@holomekc
Copy link

Describe the bug

After the deprecation of logRetention, we migrated the usage to logGroup. Sadly our logs are still full of deprecation warnings. After some debugging our assumption is that this is related to either the Provider or CustomResource construct. We tried to remove logRetention from Provider, but this does not help and there is no logGroup method available. So I assume somewhere under the hood you guys also still use logRetention.

Expected Behavior

AWS CDK internally also does not use logRetention anymore, or at least the warnings are not shown in this case.

Current Behavior

Logs are full of:

[WARNING] aws-cdk-lib.aws_lambda.FunctionOptions#logRetention is deprecated.
  instead create a fully customizable log group with `logs.LogGroup` and use the `logGroup` property to instruct the Lambda function to send logs to it.
Migrating from `logRetention` to `logGroup` will cause the name of the log group to change.
Users and code and referencing the name verbatim will have to adjust.

In AWS CDK code, you can access the log group name directly from the LogGroup construct:
\```ts
declare const myLogGroup: logs.LogGroup;
myLogGroup.logGroupName;
\```
  This API will be removed in the next major release.

Reproduction Steps

As said I did not check your code, but the assumption is when using Provider in combination with CustomResource creates this issue.

Possible Solution

  • Migrate the internal code to logGroup as well
  • Make sure that the logs are not flooded

Additional Information/Context

No response

CDK CLI Version

2.122.0

Framework Version

No response

Node.js Version

20.11.0

OS

OSX

Language

Java

Language Version

Java 17

Other information

No response

@holomekc holomekc added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jan 22, 2024
@github-actions github-actions bot added the @aws-cdk/aws-logs Related to Amazon CloudWatch Logs label Jan 22, 2024
@laurelmay
Copy link
Contributor

I think there is a fix in the works at #28783

@mrgrain mrgrain added p1 and removed needs-triage This issue or PR still needs to be triaged. labels Jan 22, 2024
@mergify mergify bot closed this as completed in #28783 Jan 22, 2024
mergify bot pushed a commit that referenced this issue Jan 22, 2024
…gGroup` (#28783)

In #28737 we have deprecated `logRetention` in favor of `logGroup`. Some custom resources have made the `logRetention` property part of their own API and are now emitting deprecation warnings with no way forward to resolve them. So we are now also deprecating `logRetention` for any custom resources.

Migrating log groups for custom resource would follow the same steps as outline in #28737. Given that custom resource logging is for debugging purposes and there are no guarantees about the output format, it should be possible to simply replace `logRetention` with a simple `logGroup` in most cases:

```ts
const awsCustom1 = new cr.AwsCustomResource(this, 'API1', {
  // Replace this
  logRetention: logs.RetentionDays.ONE_WEEK,
  // with
  logGroup: new logs.LogGroup(this, 'AwsCustomResourceLogs', {
    retention: logs.RetentionDays.ONE_WEEK,
  }),
});
```
Fixes #28806
Fixes #28809
Related to #28737

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

@saurabhmarwaha
Copy link

saurabhmarwaha commented Feb 15, 2024

@mrgrain Any solution or workaround to this yet? I am still getting this error. Specific issue is given #28809

I didn't understand what to do based on

[WARNING] aws-cdk-lib.aws_lambda.FunctionOptions#logRetention is deprecated.
instead create a fully customizable log group with logs.LogGroup and use the logGroup property to instruct the Lambda function to send logs to it.
Migrating from logRetention to logGroup will cause the name of the log group to change.
Users and code and referencing the name verbatim will have to adjust.

In AWS CDK code, you can access the log group name directly from the LogGroup construct:

declare const myLogGroup: logs.LogGroup;
myLogGroup.logGroupName;

@mrgrain
Copy link
Contributor

mrgrain commented Feb 15, 2024

@saurabhmarwaha see #28783 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-logs Related to Amazon CloudWatch Logs bug This issue is a bug. p1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants