SFM Lambda Integration naming should have the same strategy as normal Lambda Function

[barreeeiroo]

Version

v1.28.1

Steps and/or minimal code example to reproduce

When creating a monitoring segment for a Lambda Integration in a Step Function Machine, the following code should suffice to add it:

let monitoring = new MonitoringFacade(this, "MyMonitoring")
  // ...
  .monitorStepFunctionLambdaIntegration({
    lambdaFunction: anyLambdaFunction,
    humanReadableName: "Some Step"
  });

Expected behavior

The segment gets added successfully to the Dashboard.

Actual behavior

CDK fails to synthesize, and raises the following exception:

Error: Insufficient information provided for naming the alarms and/or monitoring section: Please provide alarmFriendlyName, humanReadableName, or namedConstruct as a fallback

Other details

After investigating a bit the root cause, it seems like the props sent to the MonitoringNamingStrategy to create such resource are not really correct.

For Lambda Integration in Step Function Machines (StepFunctionLambdaIntegrationMonitoring.ts#L74), they are created like this:

const namingStrategy = new MonitoringNamingStrategy({
  ...props,
  fallbackConstructName: props.lambdaFunction.functionName,
});

However, for a standard Lambda Function (LambdaFunctionMonitoring.ts#L169), they are like this:

this.namingStrategy = new MonitoringNamingStrategy({
  ...props,
  namedConstruct: props.lambdaFunction,
  fallbackConstructName: this.resolveFunctionName(props.lambdaFunction),
});

As technically the created Monitoring segment for Lambda Integration and Lambda Function should behave in the same way (they are both monitoring Lambda functions), I believe the Lambda Integration SFM should be updated to be the same one as for Lambda Function.

[T-Guerrero]

Any update on that? Faced the same issue here

[Rooster212]

I'm still experiencing this issue.

I've checked I'm using 6.2.2 which is using the latest, and I can see that the code is present in 6.2.2 here.

Disabling monitoring for step functions prevents the issue, and here is my stack trace:

From digging through, it's the error in the function getFallbackAlarmFriendlyName being thrown, which is code running after the code change linked above

I'm happy to do some more digging here and potentially raise a PR if I can work it out, but just wondering if anyone else has seen this issue.