@shatgupt Good afternoon. Thanks for opening the issue. Although unrelated to issue reproduction from CDK code perspective, at Wait for a Callback with Task Token, it's mentioned as a note that You must pass task tokens from principals within the same AWS account. The tokens won't work if you send them from principals in a different AWS account.. So, I'm unsure if Task token would work in cross-account scenario. However, refer Cross-Account waitForTaskToken in AWS Step Functions for possible workaround.

Thanks,
Ashish

Looking at the _renderTask() of the CallAwsServiceCrossRegion class:

The fix should be in how we construct the base resource ARN:

export class CallAwsServiceCrossRegion extends TaskStateBase {
  // ... existing code ...

  protected _renderTask(): any {
    // Construct the proper service integration ARN
    const serviceIntegrationArn = `arn:aws:states:::${this.service}:${this.action}`;
    
    // If using WAIT_FOR_TASK_TOKEN, the service integration ARN will automatically 
    // get .waitForTaskToken appended by the Step Functions service
    
    return {
      Resource: serviceIntegrationArn,
      Parameters: {
        region: this.region,
        parameters: this.parameters,
      },
    };
  }
}

Looking at

This shows how the resource ARN suffixes are defined for different integration patterns:

• REQUEST_RESPONSE: ''
• RUN_JOB: '.sync'
• WAIT_FOR_TASK_TOKEN: '.waitForTaskToken'

And the integrationResourceArn function that uses these suffixes.

The issue is that CallAwsServiceCrossRegion is likely not using the integrationResourceArn utility function to construct its resource ARN, which would automatically append the correct suffix based on the integration pattern.

The key difference is that instead of using the Lambda function ARN, we should be using the proper service integration ARN format. The Step Functions service will handle appending .waitForTaskToken based on the integration pattern.

This aligns better with how other service integration tasks work in the CDK.
I am requesting the team for a second look.

@ashishdhingra Thank you for mentioning that. I was aware of it and was expecting it to be pointed out that is why already mentioned it my report.

I understand that SendTaskSuccess can only be called with the token using the current account principal.

I have solved it using a similar workaround as your reference but with an SNS topic.

This probably could be its own issue but I don't think CallAwsServiceCrossRegion task would work correctly with Credentials as I don't see any assume role being done in the Lambda code for it. For context, assume role would be required to start execution of a cross-account, cross-region StateMachine since SFN doesn't have resource policies.

I am currently solving both the task token and assume role issues by creating a Lambda myself.

We should have followed this pattern 🤦

To fix this without breaking changes, I guess we can introduce payloadResponseOnly property (true by default), and then fix the _renderTask method as above. Additionally we throw an error if payloadResponseOnly == true && integrationPattern != REQUEST_RESPONSE to prevent misconfiguration. Users who needs other integration patterns can set payloadResponseOnly: false.