fix(stepfunctions): disabling logging still requires LogGroup

[Tietew]

Issue # (if applicable)

Closes #30814.

Reason for this change

To disable logging on a StateMachine (with logging enabled), we should specify LogLevel.OFF to LogOptions.level. But cannot remove the LogGroup because LogOptions.destination is required.

new sfn.StateMachine(this, 'StateMachine', {
  definitionBody: ...,
  logs: { level: sfn.LogLevel.OFF } // allow to disable logging
});

Description of changes

• Make LogOptions.destination optional.
• Validate LogOptions.destination is present when LogOptions.level is not OFF.

Description of how you validated changes

Unit and integ tests that verify LogOptions.destination is opitional when LogOptions.level is OFF and throw an exception otherwise.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

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

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[ChakshuGupta13]

will this not be a breaking change for existing usage? example:

const logOptions: LogOptions = {
  destination: <LogGroup>
}

const stateMachine: StateMachine = new StateMachine(parent, 'ID', {
  logs: logOptions,
  ...
}
... 

stateMachine.logs.destination.logGroupName // Error
stateMachine.logs.destination!.logGroupName // Change needed

Some user(s) might be utilising ILogGroup's public properties from logOptions which will now cause issues because now such users will need to make non-null assertions before using such properties (e.g. with !)

[Tietew]

According to the jsii-diff documentation:

You are allowed to make inputs optional

So i think this change is not a breaking change.

[GavinZZ]

I think @Tietew is right here. The example Chakshu mentioned is output property while the changed code is for input property.

[ChakshuGupta13]

can we not directly pass new sfn.Pass(stack, 'Pass') to DefintionBody.fromChainable as Pass implements IChainable?

[Tietew]

it's just a copy & paste.
README also uses sfn.Chain.start() instead of bare sfn.Pass.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.16%. Comparing base (7be4456) to head (e290d40).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #30816   +/-   ##
=======================================
  Coverage   82.16%   82.16%           
=======================================
  Files         119      119           
  Lines        6857     6857           
  Branches     1157     1157           
=======================================
  Hits         5634     5634           
  Misses       1120     1120           
  Partials      103      103           

Flag	Coverage Δ
suite.unit	82.16% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
packages/aws-cdk	∅ <ø> (∅)
packages/aws-cdk-lib/core	82.16% <ø> (ø)

[GavinZZ]

LGTM, thank you and apologize for the wait on the review!

[GavinZZ]

I think @Tietew is right here. The example Chakshu mentioned is output property while the changed code is for input property.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

This pull request has been removed from the queue for the following reason: pull request branch update failed.

The pull request can't be updated

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.

If you want to requeue this pull request, you need to post a comment with the text: @mergifyio requeue

[Tietew]

@Mergifyio update

[mergify]

update

❌ Mergify doesn't have permission to update

For security reasons, Mergify can't update this pull request. Try updating locally.
GitHub response: refusing to allow a GitHub App to create or update workflow .github/workflows/analytics-metadata-updater.yml without workflows permission

[aaythapa]

@mergify update

[mergify]

update

☑️ Nothing to do

• #commits-behind > 0 [📌 update requirement]
• -closed [📌 update requirement]
• -conflict [📌 update requirement]
• queue-position = -1 [📌 update requirement]

Pull request has been modified.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: e290d40
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.