Upgrade to node v24

[devksingh4]

Summary by CodeRabbit

• Chores
  • Updated Node.js runtime from version 22.x to 24.x across Lambda functions and build environments.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Updates Node.js runtime version from 22.x to 24.x across Docker build configurations in Makefile and AWS Lambda function definitions in Terraform modules. No changes to logic, configurations, or functionality beyond the version specification.

Changes

Cohort / File(s)	Summary
Docker Build Configuration Makefile	Updated Docker image tags from build-nodejs22.x to build-nodejs24.x for dist/lambda and dist/sqsConsumer runs
Terraform Lambda Runtimes terraform/modules/archival/main.tf, terraform/modules/lambdas/main.tf	Updated Lambda function runtime from nodejs22.x to nodejs24.x for api_lambda in archival module and four functions (api_lambda, sqs_lambda, hicpu_lambda, linkry_edge) in lambdas module

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Homogeneous, repetitive version updates with no logic changes
• Changes follow a consistent pattern across all affected resources
• No functional or behavioral implications

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Upgrade to node v24' accurately captures the main change: updating Node.js runtime from version 22.x to 24.x across Makefile and Terraform configuration files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch upgrade-node24

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

💰 Infracost report

Monthly estimate generated

_{This comment will be updated when code changes.}

[coderabbitai]

Actionable comments posted: 1

♻️ Duplicate comments (1)

Makefile (1)

41-41: Same image reproducibility concern as line 35.

This also uses public.ecr.aws/sam/build-nodejs24.x:latest. The verification and recommendations from the line 35 comment apply here as well.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between eb8fce5 and ffe6544.

📒 Files selected for processing (3)

• Makefile (1 hunks)
• terraform/modules/archival/main.tf (1 hunks)
• terraform/modules/lambdas/main.tf (4 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: Build Application
• GitHub Check: Run Unit Tests

🔇 Additional comments (2)

terraform/modules/archival/main.tf (1)

308-308: No action required—nodejs24.x is supported in AWS Lambda.

Node.js 24 runtime is available in all AWS regions with a projected deprecation date of April 30, 2028. The upgrade is safe to proceed.

Makefile (1)

35-35: The build-nodejs24.x image is a valid and officially documented AWS SAM image; no action needed.

The Docker image public.ecr.aws/sam/build-nodejs24.x:latest exists in the AWS SAM public ECR repository and is documented by AWS. Using the :latest tag is the standard and supported way to reference the latest version of this build image.

If stricter reproducibility is desired, you can use a specific AWS SAM CLI version tag (e.g., :1.24.1) instead of :latest, but this is optional and not required for the current build setup.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

Node.js 22 vs Node.js 24 breaking changes compatibility

💡 Result:

Summary — main breaking changes when moving from Node.js 22 → 24

1. Platform / binary support

   • Node no longer ships 32-bit Windows (since v23) and 32-bit Linux armv7 (v24). macOS pre-built binaries now require macOS 13.5+. [1]

2. OpenSSL / crypto

   • Node 24 uses OpenSSL 3.5 (security level 2) — short/weak RSA/DSA/DH/ECC keys and RC4 cipher suites are prohibited. Test TLS/crypto workloads before upgrading. [1]

3. V8, native addons and toolchain

   • V8 upgraded to 13.6 — C/C++ addons that use V8 APIs may need updates; C++20 support may be required (previously C++17). Prefer N-API to reduce rebuild work. Build toolchain minimums increased (e.g., gcc ≥ 12.2 on many Linux builds, Xcode ≥ 16.1 on macOS). [1][2]

4. HTTP / fetch / Undici

   • Undici 7 and stricter fetch() spec compliance (and removal/changes of some blob/FormData/AbortController behaviors). HTTP client behavior may change; check code that relied on older Undici/fetch edge cases. [2][3]

5. AsyncLocalStorage / async context

   • AsyncLocalStorage now uses AsyncContextFrame by default (performance and behavior differences); a flag (--no-async-context-frame) lets you revert temporarily. [2]

6. Global APIs / runtime flags

   • URLPattern is global (no import needed). Permission model matured — CLI flag simplified to --permission and is more stable. [2]

7. Behavioral and validation tightening

   • Stricter argument validation across APIs (fetch compliance, AbortSignal validation), stream/pipe errors more likely to throw, changed Buffer behavior, some path handling fixes on Windows. Expect tests to catch new exceptions. [1]

8. Deprecations / runtime removals

   • Several legacy APIs deprecated/removed (legacy url.parse usage discouraged in favor of WHATWG URL, deprecated TLS methods, REPLServer/Zlib instantiation without new, SlowBuffer → Buffer.allocUnsafeSlow(), fs.* access-mode getters deprecation — use fs.constants). Codemods are provided for some changes. [1][2]

9. Platform-specific runtime changes (examples)

   • AWS Lambda: Node.js 24 runtime drops some legacy behavior (e.g., callback-style handlers not supported in the new RIC). If deploying to Lambda, validate handler format. [4]

Quick upgrade checklist

• Run Node.js v24 locally and run full test suites (CI).
• Rebuild native modules; prefer N-API.
• Test TLS/HTTPS integrations and keys/cipher suites.
• Verify fetch/HTTP client behavior and any code depending on older Undici behavior.
• Check for reliance on deprecated APIs (url.parse, SlowBuffer, fs access getters, deprecated TLS methods).
• Validate deployment targets (OS/arch binaries, Lambda handler shape).

Sources: Node.js v22→v24 migration notes and release docs, OpenJS Foundation and ecosystem writeups, NodeSource and AWS runtime announcement. [1][2][3][4]

References
[1] Node.js v22 to v24 migration notes (Node.js project).
[2] “What’s New with Node.js 24” (OpenJS Foundation).
[3] NodeSource summary of Node.js 24 / Undici changes.
[4] AWS Compute Blog — Node.js 24 runtime for Lambda.

---

🌐 Web query:

AWS Lambda nodejs24.x runtime availability regions

💡 Result:

Node.js 24 (nodejs24.x) is available in all AWS Regions — including AWS GovCloud (US) and China Regions. [1][2]

Sources:
[1] AWS announcement: "AWS Lambda adds support for Node.js 24" (Nov 25, 2025).
[2] AWS CDK / Lambda runtimes listing showing NODEJS_24_X.

---

Test Lambda handler compatibility and validate TLS/HTTP client behavior with Node.js 24.

Four Lambda functions are being upgraded to nodejs24.x. While the runtime is available in all AWS regions, verify compatibility before merging:

1. Lambda handler format: Node.js 24 removed support for callback-style handlers in the Lambda Runtime Interface Client (RIC). Confirm all four functions use async/Promise-based handlers, not callback(err, result) patterns.
2. TLS/crypto: Node.js 24 enforces OpenSSL 3.5 security level 2, which prohibits weak RSA/DSA/DH/ECC keys and RC4 ciphers. Test any code making HTTPS requests or handling TLS certificates.
3. HTTP/fetch: Undici 7 introduces stricter fetch() spec compliance. Validate fetch/HTTP client code, especially any code relying on edge cases or FormData/blob behavior.
4. Native modules: If any dependencies use native C/C++ addons, they may require rebuilds for V8 13.6 compatibility; prefer N-API modules.

Run full test suites with Node.js 24 locally before deploying.

Also applies to: 383-383, 414-414, 513-513

🤖 Prompt for AI Agents

In terraform/modules/lambdas/main.tf around lines 354, 383, 414 and 513, you
bumped the runtime to nodejs24.x but the PR comment requests verification and
fixes for Node.js 24 incompatibilities: audit each Lambda's handler source to
ensure they export async/Promise-based handlers (remove or migrate any
callback(err,result) patterns), run the full test suite locally using Node.js 24
to exercise TLS/crypto and HTTP code paths, exercise any HTTPS requests and
certificate handling to confirm OpenSSL 3.5+ security level 2 compatibility
(replace weak keys/ciphers or strengthen certs), test code that uses
fetch/undici for spec compliance and update FormData/blob usage as needed,
rebuild any native addons (or replace with N-API modules) and update lockfiles,
and only merge after all unit/integration tests pass under Node.js 24.