feat: invalidate cloudfront cache after updating json by Perry2004 · Pull Request #71 · Perry2004/perry2004.github.io

Perry2004 · 2025-11-08T18:35:34Z

No description provided.

Copilot

Pull Request Overview

This PR adds CloudFront cache invalidation functionality to the Lambda handler to ensure that updated image data is immediately reflected on the website after being uploaded to S3.

Key Changes:

Integrates AWS CloudFront SDK to create cache invalidations after S3 uploads
Implements distribution lookup by Name tag for dynamic configuration
Updates environment variable configuration for CloudFront distribution identification

Reviewed Changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
scripts/src/lambda-handler.ts	Adds CloudFront client, getDistributionIdByName function, and cache invalidation logic after S3 upload
scripts/package.json	Adds @aws-sdk/client-cloudfront dependency version 3.927.0
scripts/package-lock.json	Updates lock file with CloudFront client dependencies and transitive dependencies
scripts/Dockerfile.script	Adds CLOUDFRONT_DISTRIBUTION_ID environment variable configuration
.github/workflows/build-lambda-image.yaml	Passes CLOUDFRONT_DISTRIBUTION_ID build argument to Docker build

Files not reviewed (1)

scripts/package-lock.json: Language not supported

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-11-08T18:38:20Z

scripts/src/lambda-handler.ts

+    for (const distribution of listResponse.DistributionList.Items) {
+      if (!distribution.ARN || !distribution.Id) {
+        continue;
+      }
+
+      try {
+        const tagsCommand = new ListTagsForResourceCommand({
+          Resource: distribution.ARN,
+        });
+        const tagsResponse = await cloudfrontClient.send(tagsCommand);
+
+        const nameTag = tagsResponse.Tags?.Items?.find(
+          (tag) => tag.Key === "Name" && tag.Value === name,
+        );
+
+        if (nameTag) {
+          console.log(
+            `Found distribution ID: ${distribution.Id} for Name: ${name}`,
+          );
+          return distribution.Id;
+        }
+      } catch (tagError) {
+        console.error(
+          `Error fetching tags for distribution ${distribution.Id}: ${tagError}`,
+        );
+        continue;
+      }
+    }


The getDistributionIdByName function makes N+1 API calls by listing all distributions and then making a separate ListTagsForResourceCommand call for each distribution. This is inefficient and can lead to performance issues, especially with many distributions or rate limiting.

Consider alternatives such as:

Using CloudFront distribution aliases/CNAMEs if applicable

Passing the distribution ID directly as an environment variable instead of looking it up by Name tag

Caching the distribution ID lookup result if this Lambda runs frequently

Copilot · 2025-11-08T18:38:20Z

scripts/src/lambda-handler.ts

+            CallerReference: `lambda-${Date.now()}`,
+            Paths: {
+              Quantity: 1,
+              Items: [`/${key.replace("website/", "")}`],


The path transformation logic key.replace("website/", "") may produce unexpected results if the key doesn't contain "website/". The current implementation would invalidate /data/rolling-images.json, but if the key format changes or doesn't contain "website/", this could silently fail or invalidate the wrong path.

Consider making this more explicit:

const cloudfrontPath = `/${key.startsWith("website/") ? key.substring(8) : key}`;

Or validate that the key has the expected format before proceeding.

Suggested change

Items: [`/${key.replace("website/", "")}`],

Items: [`/${key.startsWith("website/") ? key.substring(8) : key}`],

Copilot · 2025-11-08T18:38:21Z

scripts/src/lambda-handler.ts

+      const BUCKET_NAME = process.env.S3_BUCKET_NAME;
+      const CLOUDFRONT_DISTRIBUTION_NAME =
+        process.env.CLOUDFRONT_DISTRIBUTION_NAME;
      const key = "website/data/rolling-images.json";


[nitpick] The key path "website/data/rolling-images.json" is hardcoded and appears in multiple places (line 98 for the key itself, and line 208 where "website/" is stripped for CloudFront invalidation). This creates a maintainability issue if the path structure needs to change.

Consider extracting this as a constant at the module level:

const S3_KEY = "website/data/rolling-images.json"; const CLOUDFRONT_PATH_PREFIX = "website/";

This would make the relationship between S3 and CloudFront paths more explicit and easier to maintain.

Copilot · 2025-11-08T18:38:21Z

scripts/Dockerfile.script

+ARG CLOUDFRONT_DISTRIBUTION_ID
+ENV CLOUDFRONT_DISTRIBUTION_ID=${CLOUDFRONT_DISTRIBUTION_ID}


Environment variable name mismatch detected. The Dockerfile sets CLOUDFRONT_DISTRIBUTION_ID, but the lambda-handler.ts expects CLOUDFRONT_DISTRIBUTION_NAME. This will cause the Lambda function to fail at runtime with a "Missing CloudFront configuration" error.

Either change the Dockerfile to use CLOUDFRONT_DISTRIBUTION_NAME or update the lambda-handler.ts to read CLOUDFRONT_DISTRIBUTION_ID.

Suggested change

ARG CLOUDFRONT_DISTRIBUTION_ID

ENV CLOUDFRONT_DISTRIBUTION_ID=${CLOUDFRONT_DISTRIBUTION_ID}

ARG CLOUDFRONT_DISTRIBUTION_NAME

ENV CLOUDFRONT_DISTRIBUTION_NAME=${CLOUDFRONT_DISTRIBUTION_NAME}

Copilot

Pull Request Overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated 4 comments.

Files not reviewed (1)

scripts/package-lock.json: Language not supported

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-11-08T18:47:46Z

scripts/src/lambda-handler.ts

+      } catch (cfError) {
+        console.error(`Error creating CloudFront invalidation: ${cfError}`);
+        return {
+          statusCode: 500,
+          body: JSON.stringify({
+            success: false,
+            error: cfError instanceof Error ? cfError.message : String(cfError),
+            message: "Failed to invalidate CloudFront cache",
+            image_links: imageLinks,
+            total_count: imageLinks.length,
+            s3_location: `s3://${BUCKET_NAME}/${key}`,
+          }),
+        };
+      }


Returning a 500 error when CloudFront invalidation fails could be misleading since the S3 upload already succeeded. Consider either:

Returning a 207 (Multi-Status) or 200 with a warning indicating partial success

Making CloudFront invalidation non-blocking and logging the error instead

Implementing a rollback mechanism to delete the S3 object if invalidation fails

The current approach could cause the Lambda to be retried unnecessarily even though the S3 upload succeeded.

Copilot · 2025-11-08T18:47:47Z

scripts/src/lambda-handler.ts

      }

+      // Invalidate CloudFront cache for the updated file
+      let invalidationId = null;


The variable invalidationId should be explicitly typed. Consider changing:

let invalidationId: string | undefined;

This makes the type clearer and avoids relying on null which might not match the API response type.

Suggested change

let invalidationId = null;

let invalidationId: string | undefined;

Copilot · 2025-11-08T18:47:47Z

scripts/src/lambda-handler.ts

+        const invalidationCommand = new CreateInvalidationCommand({
+          DistributionId: CLOUDFRONT_DISTRIBUTION_ID,
+          InvalidationBatch: {
+            CallerReference: `lambda-${Date.now()}`,


[nitpick] Using Date.now() for CallerReference could potentially cause issues if multiple Lambda invocations happen within the same millisecond. While unlikely, consider using a more robust unique identifier like crypto.randomUUID() or combining timestamp with a random component:

CallerReference: `lambda-${Date.now()}-${Math.random().toString(36).substring(7)}`,

Copilot · 2025-11-08T18:47:47Z

scripts/package.json

        "dev": "ts-node src/main.ts"
    },
    "dependencies": {
+        "@aws-sdk/client-cloudfront": "^3.927.0",


[nitpick] The @aws-sdk/client-cloudfront version (^3.927.0) is newer than @aws-sdk/client-s3 (^3.922.0). While this shouldn't cause issues due to the caret (^) range, consider using the same minor version for consistency across AWS SDK packages to avoid potential compatibility issues:

"@aws-sdk/client-cloudfront": "^3.922.0",

Suggested change

"@aws-sdk/client-cloudfront": "^3.927.0",

"@aws-sdk/client-cloudfront": "^3.922.0",

Copilot AI review requested due to automatic review settings November 8, 2025 18:35

Copilot AI reviewed Nov 8, 2025

View reviewed changes

feat: invalidate cloudfront cache after updating json

df030ca

Perry2004 force-pushed the feat/invalidate-cache-after-update branch from 71f0053 to df030ca Compare November 8, 2025 18:44

Perry2004 requested a review from Copilot November 8, 2025 18:45

Copilot AI reviewed Nov 8, 2025

View reviewed changes

Perry2004 merged commit 4fc50aa into main Nov 8, 2025
8 checks passed

Perry2004 deleted the feat/invalidate-cache-after-update branch November 8, 2025 18:48

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: invalidate cloudfront cache after updating json#71

feat: invalidate cloudfront cache after updating json#71
Perry2004 merged 1 commit intomainfrom
feat/invalidate-cache-after-update

Perry2004 commented Nov 8, 2025

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Nov 8, 2025

Uh oh!

Copilot AI Nov 8, 2025

Uh oh!

Copilot AI Nov 8, 2025

Uh oh!

Copilot AI Nov 8, 2025

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Nov 8, 2025

Uh oh!

Copilot AI Nov 8, 2025

Uh oh!

Copilot AI Nov 8, 2025

Uh oh!

Copilot AI Nov 8, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	Items: [`/${key.replace("website/", "")}`],
	Items: [`/${key.startsWith("website/") ? key.substring(8) : key}`],

		ARG CLOUDFRONT_DISTRIBUTION_ID
		ENV CLOUDFRONT_DISTRIBUTION_ID=${CLOUDFRONT_DISTRIBUTION_ID}

	let invalidationId = null;
	let invalidationId: string \| undefined;

	"@aws-sdk/client-cloudfront": "^3.927.0",
	"@aws-sdk/client-cloudfront": "^3.922.0",

Conversation

Perry2004 commented Nov 8, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Copilot AI Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants