Switch to node 14 #219
Switch to node 14 #219
Conversation
WalkthroughAdded a Maven validation-api dependency, hardened a React side-drawer component with null guards around array maps and normalized prop forwarding, and changed the Node.js version in the CI pr-check workflow from 20 to 14. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
components/org.wso2.micro.integrator.dashboard.web/web-app/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (2)
components/org.wso2.dashboard.security.user.core/pom.xml(1 hunks)components/org.wso2.micro.integrator.dashboard.web/web-app/src/commons/sideDrawers/ApiSideDrawer.js(3 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
components/org.wso2.micro.integrator.dashboard.web/web-app/src/commons/sideDrawers/ApiSideDrawer.js (2)
components/org.wso2.micro.integrator.dashboard.web/web-app/src/commons/EnhancedTable.js (1)
retrieveUpdatedArtifact(120-144)components/org.wso2.micro.integrator.dashboard.web/web-app/src/commons/sideDrawers/commons/TracingRow.js (2)
TracingRow(28-72)props(29-29)
🔇 Additional comments (5)
components/org.wso2.micro.integrator.dashboard.web/web-app/src/commons/sideDrawers/ApiSideDrawer.js (5)
54-54: LGTM: Explicit prop forwarding improves clarity.The explicit
retrieveUpdatedArtifact={retrieveUpdatedArtifact}prop forwarding makes the component interface clearer and more maintainable.
92-94: LGTM: Null guard prevents runtime errors.The
urls &&guard prevents potential runtime errors ifurlListis undefined or null, which is good defensive programming.
102-102: LGTM: Explicit prop forwarding aligns with TracingRow expectations.Based on the TracingRow implementation (TracingRow.js:27-71), this component requires
retrieveUpdatedArtifactto update the UI after tracing status changes. The explicit prop forwarding is correct.
108-128: LGTM: Null guard prevents runtime errors.The
resources &&guard prevents potential runtime errors ifresourcesis undefined or null, which is good defensive programming practice.
37-70: Update PR title to reflect actual changes.The PR title "Switch to node 14" doesn't match the actual code changes in this PR. No Node.js version configuration files (
.nvmrc,.node-version,package.jsonengines field, or CI/CD configs) have been modified. The changes are defensive null guards and explicit prop forwarding in the ApiSideDrawer component. Either update the PR title to describe the actual changes, or verify whether the Node.js version upgrade is being handled in a separate commit.Likely an incorrect or invalid review comment.
| <dependency> | ||
| <groupId>javax.validation</groupId> | ||
| <artifactId>validation-api</artifactId> | ||
| <version>2.0.1.Final</version> | ||
| </dependency> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if validation-api classes are used in the Java source files
# Search for common validation-api imports and annotations
echo "=== Searching for javax.validation imports ==="
rg -n --type=java 'import javax\.validation\.' -g '!**/target/**' 2>/dev/null | head -20
echo -e "\n=== Searching for validation annotations usage ==="
rg -n --type=java '@Valid|@NotNull|@NotEmpty|@Size|@Pattern' -g '!**/target/**' 2>/dev/null | head -30
echo -e "\n=== Checking pom.xml files for validation-api references ==="
rg -n 'validation-api' 2>/dev/null
echo -e "\n=== Checking if jakarta.validation is already used ==="
rg -n --type=java 'import jakarta\.validation\.' -g '!**/target/**' 2>/dev/nullRepository: wso2/integration-control-plane
Length of output: 8040
🌐 Web query:
What is the latest stable version of jakarta.validation-api as of 2025?
💡 Result:
The latest stable release is jakarta.validation:jakarta.validation-api version 3.1.1 (released Feb 1, 2025). [1][2]
Sources:
- Maven Central listing for jakarta.validation-api 3.1.1. [1]
- Javadoc.io / package metadata showing latest version 3.1.1. [2]
🌐 Web query:
Are there any known security vulnerabilities in javax.validation validation-api version 2.0.1.Final?
💡 Result:
Short answer: No known security vulnerabilities have been reported for the javax.validation:validation-api 2.0.1.Final artifact itself. As of Dec 4, 2025, vulnerability databases (e.g., Snyk) list no direct vulnerabilities for that package. [1]
Note: there are known vulnerabilities in implementations (e.g., Hibernate Validator CVE-2020-10693) that affect message interpolation in certain versions of the implementation — those are not vulnerabilities in the validation-api spec artifact but can impact applications using vulnerable implementations. Check your validator implementation/version for CVEs. [2][3]
Sources:
- Snyk package page for javax.validation:validation-api 2.0.1.Final — no direct vulnerabilities. [1]
- NVD entry for CVE-2020-10693 (Hibernate Validator implementation). [2]
- Analysis writeup summarizing CVE-2020-10693. [3]
Migrate to jakarta.validation-api; dependency is actively used and version is outdated.
The javax.validation dependency is actively used across the codebase (JDBCUserStoreManager.java, AddRoleRequest.java, and 20+ other files use @Valid, @NotNull, and other validation annotations). However, version 2.0.1.Final dates from 2017 and the javax.validation namespace has been superseded by jakarta.validation as part of Jakarta EE's modernization.
Migrate to jakarta.validation-api:3.1.1 (latest stable as of February 2025) and update all imports from javax.validation.* to jakarta.validation.* across the codebase. No direct security vulnerabilities exist in the 2.0.1.Final API package itself, but adopting the modern Jakarta namespace aligns with current best practices and future maintenance.
🤖 Prompt for AI Agents
In components/org.wso2.dashboard.security.user.core/pom.xml around lines 78-82,
the project currently depends on javax.validation:validation-api:2.0.1.Final;
replace this dependency with jakarta.validation:jakarta.validation-api:3.1.1 and
remove the old javax.validation entry, then update all Java source imports
across the codebase (e.g., JDBCUserStoreManager.java, AddRoleRequest.java and
the ~20+ other files) from javax.validation.* to jakarta.validation.* (use your
IDE’s refactor/replace tool or a project-wide sed/grep to change imports,
rebuild the project, and fix any compilation issues such as package name changes
in annotations or Validator APIs).
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
components/org.wso2.micro.integrator.dashboard.web/web-app/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (1)
.github/workflows/pr-check.yml(1 hunks)
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: "20" | ||
| node-version: "14" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check the current state of the workflow file and any related context
cat -n .github/workflows/pr-check.ymlRepository: wso2/integration-control-plane
Length of output: 2613
🏁 Script executed:
# Search for Node.js version references in the repository
rg "node-version" --type yaml -B 2 -A 2Repository: wso2/integration-control-plane
Length of output: 56
🏁 Script executed:
# Check git history for this file to see if there was a previous version with Node 20
git log --oneline -10 -- .github/workflows/pr-check.ymlRepository: wso2/integration-control-plane
Length of output: 129
🏁 Script executed:
# Look for related issues or documentation about Node.js version choices
rg "node.*14|node.*20" --type md -iRepository: wso2/integration-control-plane
Length of output: 154
🌐 Web query:
Node.js 14 end of life date and support status
💡 Result:
Node.js 14 (Fermium) reached End‑of‑Life on April 30, 2023 — it is no longer supported (no more updates or security fixes). [1][2]
Sources:
- Node.js official EOL page. [1]
- Third‑party lifecycle summary (dates). [2]
🌐 Web query:
Node.js 20 LTS support timeline
💡 Result:
Node.js 20 (codename "Iron") — key support dates:
- Initial release: April 18, 2023. [1]
- Entered Active LTS: October 24, 2023. [1][2]
- Moved to Maintenance LTS: October 22, 2024. [2]
- End-of-life (EOL): April 30, 2026. [2][3]
Sources: Node.js release announcement (v20.9.0) and Node.js Release WG schedule. [1][2] Additional EOL listings confirm April 30, 2026. [3]
References
[1] Node.js blog — v20.9.0 (LTS) announcement.
[2] nodejs/Release (Release schedule) on GitHub.
[3] eol.support / Node.js release EOL listing.
🏁 Script executed:
# Check git diff for this specific file to see what changed
git diff HEAD~1 .github/workflows/pr-check.yml 2>/dev/null || git show HEAD:.github/workflows/pr-check.yml 2>/dev/null | head -30Repository: wso2/integration-control-plane
Length of output: 659
🏁 Script executed:
# Check if there's a PR or branch context that shows the actual change
git log --all --oneline --grep="node" -i | head -10Repository: wso2/integration-control-plane
Length of output: 807
🏁 Script executed:
# Look at the most recent commit details for pr-check.yml
git show --stat HEAD -- .github/workflows/pr-check.yml 2>/dev/null | head -40Repository: wso2/integration-control-plane
Length of output: 442
Node.js 14 (EOL since April 2023) introduces security and maintenance risks in CI/CD.
Node.js 14 reached End-of-Life on April 30, 2023 and no longer receives security updates. This downgrade from Node.js 20 (LTS until April 2026) creates security exposure for your CI/CD pipeline and may cause dependency compatibility issues as packages drop Node 14 support.
While the README documents Node.js 14 as a project requirement, this appears to be a legacy constraint. If Node 14 is required for development compatibility, clarify this rationale in the PR. Otherwise, consider upgrading the project to a supported LTS version (Node.js 20 or 22) and updating documentation accordingly.
🤖 Prompt for AI Agents
.github/workflows/pr-check.yml around line 28: the workflow pins node-version to
"14" which is EOL and poses security/compatibility risks; update the CI to use a
supported LTS (e.g., "20" or "22") by changing the node-version entry
accordingly, and if the project truly requires Node 14 for local development
instead of CI, add a clear justification in the PR and update README to document
that constraint; also check other CI/workflow/matrix entries and package.json
engines field and update them to match the chosen supported Node version.
2 participants
Purpose
Summary by CodeRabbit
Bug Fixes
Chores
✏️ Tip: You can customize this high-level summary in your review settings.