aws-elasticsearch/aws-opensearch: lambda resource synth not stable between linux and windows

[fknittel]

What is the problem?

Since 1.123.0 the lambda resources brought in by use of aws-elasticsearch constructs produce different synth values for Linux and Windows. This is a problem for us, as we use the synth results as goldenmaster tests and have Windows on the dev machines and Linux on the CI machines.

I assume that this also affects custom Lambdas, but our problem is specifically with the aws-elasticsearch use.

Reproduction Steps

I've prepared a simple reproduction project, starting with cdk init and a stack containing an example Domain construct copy&pasted from the documentation and a simple test case that highlights which elements of the synth result differ between platforms. Please see the three branches

• https://github.com/fknittel/cdk-elasticsearch-synth-delta-reproducer/tree/working-1.122.0-elasticsearch,
• https://github.com/fknittel/cdk-elasticsearch-synth-delta-reproducer/tree/broken-1.123.0-elasticsearch and
• https://github.com/fknittel/cdk-elasticsearch-synth-delta-reproducer/tree/broken-1.127.0-opensearch

I've added github actions that hopefully highlight the problem. The test works on both platforms for 1.122.0 but produces different results between Linux and Windows on 1.123.0 up to 1.127.0.

What did you expect to happen?

I expected the same (construct internal) lambda resources to get synthesized, regardless of the platform the synth is performed on.

What actually happened?

The synth differs between Linux and Windows.

CDK CLI Version

1.127.0 (build 0ea309a)

Framework Version

1.127.0 (also affects >= 1.123.0)

Node.js Version

v16.11.0 / v14.18.0

OS

Linux and Windows

Language

Typescript, Java

Language Version

TypeScript (3.9.10) | Java (11)

Other information

I've tried to make it easily reproducible in the referenced repo. If you need anything else, please don't hesitate.

We're currently stuck on 1.122.0 due to this issue.

After some research I found #14555, but I'm not sure whether it's the same issue. Please advise.

[peterwoodworth]

@jogold I'd appreciate if you could take a look at this, thanks!

[jogold]

Thanks for the very detailed bug report @fknittel!

I was able to reproduce this and found the problem:

• v1.123.0 introduced a patch for AWS SDK in the custom resource (see https://github.com/aws/aws-cdk/tree/v1.123.0/packages/@aws-cdk/custom-resources/lib/aws-custom-resource/runtime/aws-sdk-patch)
• This patch is located in a subfolder named aws-sdk-patch
• The hashing algorithm includes the relative path of a file in the hash

aws-cdk/packages/@aws-cdk/core/lib/fs/fingerprint.ts

Line 73 in 8f91531

_hashField(hash, `file:${relativePath}`, contentFingerprint(realPath));

• This relative path uses \ on windows but / on linux

In versions < 1.123.0 there were no subfolders in the custom resource's "asset", relatives path were : index.d.ts and index.js => no differences between windows and linux

Opening a PR to fix this.

[github-actions]

⚠️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.