(s3-deployment): cross stack values do not work with Source.data/jsonData

[johnameyer]

What is the problem?

Source.data/jsonData resolves values from within a stack successfully but creates references to out-of stack values in the template as if they were in the same stack.

Reproduction Steps

class OneStack extends Stack {
    public pool: UserPool;

	constructor(scope: Construct, id: string) {
        super(scope, id);
        this.pool = new UserPool(this, 'UserPool');
    }
}

class TwoStack extends Stack {
	constructor(scope: Construct, id: string, one: OneStack) {
        super(scope, id);
        const destinationBucket = new Bucket(this, 'Bucket');

        new BucketDeployment(this, 'Deployment', {
			sources: [
				Source.jsonData('config.js',  one.pool.userPoolProviderUrl)
			],
			destinationBucket
		});
    }
}

const app = new App();

const one = new OneStack(app, 'One');
new TwoStack(app, 'Two', one);

app.synth()

What did you expect to happen?

Successful deployment and inclusion of resolved value in deployed file by way of generating cross stack imports/exports as would usually result.

What actually happened?

$ cdk deploy
...
Two: creating CloudFormation changeset...

 ❌  Two failed: Error [ValidationError]: Template format error: Unresolved resource dependencies [UserPoolWXYZ1234] in the Resources block of the template

CDK CLI Version

2.14.0

Framework Version

2.14.0

Node.js Version

v14.19.0

OS

WSL

Language

Typescript

Language Version

Typescript (~4.5.5)

Other information

Ref to previous comment/original issue: #12903 (comment)

[NGL321]

Hey @johnameyer,

Thanks for reporting this. I have verified the behavior, this certainly seems like a problem. If you come up with a fix and would like to implement it yourself (fastest approach), please @ myself or otaviomacedo (who reviewed the last similar PR) to get a quicker review.

[AKoetsier]

It looks like this is related to #18882

[kb3eua]

I'm experiencing the exact same issue. I even tried using CfnOutput/cdk.Fn.importValue() as a workaround but that just results in a different error: Invalid CloudFormation reference. "Ref" or "Fn::GetAtt". Got {"Fn::ImportValue":"CognitoUserPoolId"}

[thejimmyg]

I'm hitting exactly the same issue. Please could someone from AWS take a look urgently?

[AKoetsier]

Although not a fix, I managed to work around it by creating an SSM parameter using the cross account references and use the value (stringValue) of the parameter in the data/jsonData.

[thejimmyg]

Thanks @AKoetsier. I've temporarily re-written as a single stack to avoid the cross-stack references. This works fine at the moment so is worth bearing in mind as another option for anyone else coming to this issue.

[Nath-P]

Although not a fix, I managed to work around it by creating an SSM parameter using the cross account references and use the value (stringValue) of the parameter in the data/jsonData.

thanks for the hint @AKoetsier, I hit this today and worked around it pretty quickly with an ssm parameter

[revmischa]

Running into this exact issue

[johnameyer]

Any update here? I'm happy to contribute a fix if someone more familiar could assist in root causing why these references aren't being picked up

[Aeolun]

From what I can see, the library just doesn't consider cross stack references at all. Only values within the same stack can be (easily) resolved.

[thantos]

Did a bit of a deep dive here, I am not sure how to fix it, but I figured out why StringParameter works and Source.data/jsonData does not.

When StringParameter is given a Token, it passes it directly to CfnParameter and then rendered directly to the template. In this case, the cross stack references are rendered as...

       {
        "Fn::ImportValue": "[otherstack]:ExportsOutputRef[resource id]"
       }

When BucketDeploy resolves references (via Stack.resolve) they are always resolved as their bare Ref and never the cross stack reference.

{"Ref":"[resource id]"}

[peterwoodworth]

I know this is the original issue, but I'm closing it in favor of the newer one submitted here set to be closed by a PR. Thanks for the discussion! Feel free to continue on the newer issue