Bumping lambda runtimes

[julgmz]

No description provided.

[github-actions]

Resolves #433

[julgmz]

was in dev deps unnecessarily

[coderabbitai]

Walkthrough

The changes update the Node.js runtime specification across multiple Lambda functions from implicit defaults to explicit Node.js 24.x configuration. This involves adding the Runtime import from aws-lambda to four service configuration files (firehose-config, migration-lambda, opensearch-bootstrap, and timing-config) and setting the runtime property to Runtime.NODEJS_24_X on their respective NodejsFunction definitions. Additionally, the aws-cdk-lib dependency is upgraded from version 2.200.1 to 2.228.0 in the package.json configuration.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description check	❓ Inconclusive	No description was provided by the author, making it impossible to assess whether the description is related to the changeset.	Add a pull request description explaining the motivation for bumping Lambda runtimes to Node.js 24.x and any relevant testing or compatibility considerations.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: updating Lambda runtime versions across multiple infrastructure files from default to Node.js 24.x.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ito-433

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bc40198 and 6123c30.

📒 Files selected for processing (5)

• server/infra/lib/service/firehose-config.ts (3 hunks)
• server/infra/lib/service/migration-lambda.ts (2 hunks)
• server/infra/lib/service/opensearch-bootstrap.ts (2 hunks)
• server/infra/lib/timing-config.ts (2 hunks)
• server/infra/package.json (1 hunks)

🧰 Additional context used

📓 Path-based instructions (6)

**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always prefer console commands over log commands. Use console.log instead of log.info

Files:

• server/infra/lib/service/migration-lambda.ts
• server/infra/lib/service/opensearch-bootstrap.ts
• server/infra/lib/service/firehose-config.ts
• server/infra/lib/timing-config.ts

**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/always.mdc)

Never use empty catch statements

Files:

• server/infra/lib/service/migration-lambda.ts
• server/infra/lib/service/opensearch-bootstrap.ts
• server/infra/lib/service/firehose-config.ts
• server/infra/lib/timing-config.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/code-conventions.mdc)

**/*.{ts,tsx}: Follow standard, idiomatic TypeScript coding practices for structure, naming, and types
Avoid adding comments unless they explain complex logic or non-obvious decisions; well-written, self-explanatory code is preferred
Do not add comments that merely restate what the code does
Rely on comprehensive tests to document the behavior and usage of code rather than extensive comments within the code itself
Use kebab-case when naming directories, TypeScript, and other files

**/*.{ts,tsx}: Prefer interfaces over types for object definitions
Use type for unions, intersections, and mapped types
NEVER use any or as any types or coercion
Leverage TypeScript's built-in utility types
Use generics for reusable type patterns
Use PascalCase for type names and interfaces
Use camelCase for variables and functions
Use UPPER_CASE for constants
Use descriptive names with auxiliary verbs (e.g., isLoading, hasError)
Prefix interfaces for React props with 'Props' (e.g., ButtonProps)
Keep type definitions close to where they're used
Export types and interfaces from dedicated type files when shared
Co-locate component props with their components
Use explicit return types for public functions
Use arrow functions for callbacks and methods
Implement proper error handling with custom error types
Use function overloads for complex type scenarios
Prefer async/await over Promises
Prefer function declarations over function expressions
Use readonly for immutable properties
Leverage discriminated unions for type safety
Use type guards for runtime type checking
Implement proper null checking
Avoid type assertions unless necessary
Handle Promise rejections properly

Files:

• server/infra/lib/service/migration-lambda.ts
• server/infra/lib/service/opensearch-bootstrap.ts
• server/infra/lib/service/firehose-config.ts
• server/infra/lib/timing-config.ts

server/**/*.{ts,js}

📄 CodeRabbit inference engine (AGENTS.md)

Backend code and database migrations should be organized in server/ using Bun

Files:

• server/infra/lib/service/migration-lambda.ts
• server/infra/lib/service/opensearch-bootstrap.ts
• server/infra/lib/service/firehose-config.ts
• server/infra/lib/timing-config.ts

{app,lib,server}/**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (AGENTS.md)

{app,lib,server}/**/*.{ts,tsx,js,jsx}: Use ESLint to enforce code style and run bun run lint before submitting code
Always use console commands instead of log commands (e.g., console.log instead of log.info)

Files:

• server/infra/lib/service/migration-lambda.ts
• server/infra/lib/service/opensearch-bootstrap.ts
• server/infra/lib/service/firehose-config.ts
• server/infra/lib/timing-config.ts

{app,lib,server}/**/*.{ts,tsx,js}

📄 CodeRabbit inference engine (AGENTS.md)

Constants use SCREAMING_SNAKE_CASE naming convention

Files:

• server/infra/lib/service/migration-lambda.ts
• server/infra/lib/service/opensearch-bootstrap.ts
• server/infra/lib/service/firehose-config.ts
• server/infra/lib/timing-config.ts

⏰ 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). (3)

• GitHub Check: run-tests / test
• GitHub Check: Analyze (swift)
• GitHub Check: Analyze (rust)

🔇 Additional comments (2)

server/infra/package.json (1)

29-29: Upgrade is safe and recommended - removes security vulnerabilities with no codebase impact.

Minor and patch releases are backward compatible; code written in a previous version with the same major version can be upgraded to a newer version within the same major version. The codebase does not use the reference interfaces that were relocated or any of the affected L1 constructs (Neptune, OpenSearchServerless, ServiceCatalog).

The upgrade fixes all security advisories: all 5 known vulnerabilities (highest patched in 2.189.1) are removed by upgrading to 2.228.0, including moderate-severity issues in Cognito and IAM configurations. The services this codebase depends on (ECS, Lambda, S3, RDS, OpenSearch, Cognito, IAM) are mature, stable modules unaffected by the L1 schema changes in this version range.

server/infra/lib/service/firehose-config.ts (1)

15-15: No issues found — Node.js 24.x runtime is officially supported and consistently configured.

AWS Lambda officially lists Node.js 24 (nodejs24.x) as a supported runtime as of November 25, 2025. The aws-cdk-lib version 2.228.0 supports Runtime.NODEJS_24_X. The import is necessary and correct, and runtime configuration is consistent across all Lambda functions in the codebase (timing-config.ts, opensearch-bootstrap.ts, migration-lambda.ts, and firehose-config.ts).

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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