[Customer Portal][BE] Update updates/search response and improve vulnerability not-found handling

[Rashmika998]

Description

This PR cleans up unused fields in the updates/search response and improves the not-found handling for the vulnerability get endpoint.

Changes

updates/search Response Cleanup

Removed the following unused fields from the updates service response:

• jwt
• platform-name
• platform-version

Updated related DTOs and mappings to reflect the cleaned response structure.

Vulnerability Not-Found Handling

• Improved not-found scenario for the vulnerability get endpoint
• Ensured proper HTTP status code (e.g., 404) is returned
• Standardized error response structure

Reason

Response Cleanup

The fields jwt, platform-name, and platform-version were present in the response but not used by the system. Keeping them:

• Added unnecessary payload size
• Created confusion around authentication and platform metadata
• Increased coupling with the upstream service

Removing them simplifies the response contract and keeps the API clean.

Not-Found Improvement

The vulnerability get endpoint previously did not handle missing resources clearly. This update ensures:

• Proper 404 responses
• Consistent error messaging
• Better API contract clarity

Testing

• Verified updated updates/search response structure
• Confirmed no dependency on removed fields
• Tested vulnerability get endpoint with valid and invalid IDs
• Ensured correct 404 behavior and response format

Impact

• Response structure simplified (removal of unused fields)
• Improved error handling (non-breaking behavioral improvement)

Checklist

• Unused fields removed
• DTOs updated
• 404 handling verified

Summary by CodeRabbit

• Bug Fixes

  • Improved API response handling for update searches by wrapping results in proper HTTP success responses.
  • Added 404 Not Found handling for product vulnerability lookups.

• Refactor

  • Simplified update response payload by removing redundant platform/auth fields and normalizing field names.
  • Enhanced update metadata to include richer level details for more consistent client display.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Refactored UpdateResponse and related update-level types: removed jwt/platform fields, renamed productBaseVersion→productVersion and appliedUpdateNumbers→appliedUpdatesNumbers, added open json... fields, updated mapping logic in update utilities, and changed two service endpoint signatures to wrap/handle responses differently.

Changes

Cohort / File(s)	Summary
Core type updates apps/customer-portal/backend/modules/types/types.bal, apps/customer-portal/backend/modules/updates/types.bal	Removed jwt, platformName, platformVersion from UpdateResponse; renamed productBaseVersion → productVersion and appliedUpdateNumbers → appliedUpdatesNumbers; added open json... fields to update-level related types.
Update utilities apps/customer-portal/backend/modules/updates/utils.bal	Adjusted response construction/mapping in processListUpdates to remove old fields and emit renamed/added fields (productVersion, appliedUpdatesNumbers, etc.).
Service signatures / handlers apps/customer-portal/backend/service.bal	Changed POST /updates/search to return http:Ok wrapping the response; extended GET /products/vulnerabilities/[id] to return http:NotFound when appropriate and adjusted return types.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• [Customer Portal][BE] Add updates endpoints #98 — Modifies the same update types and response mapping (UpdateResponse renames/removals) and aligns with changes here.
• [Customer Portal][BE] Standardize update API field names in requests and responses #124 — Touches UpdateResponse fields (productBaseVersion/productVersion and appliedUpdateNumbers/appliedUpdatesNumbers) across customer-portal modules.
• [Customer Portal][BE] Refactor types.bal into module and standardize update API response field names #155 — Also renames/removes update-related fields and updates type declarations used by the updates flow.

Suggested reviewers

• shayanmalinda
• kasunsiyambalapitiya

Poem

🐰✨ I hopped through types both old and new,
jwt and platform fields bid adieu,
productVersion hops into place,
appliedUpdatesNumbers joins the race,
JSON fields wiggle with joyful hue.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the two main changes: cleaning up unused fields in updates/search response and improving vulnerability not-found handling.
Description check	✅ Passed	The description comprehensively covers purpose, goals, approach, testing, and impact. While it doesn't follow the template exactly, it provides all necessary information for understanding the PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into customer-portal-milestone-1

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/customer-portal/backend/modules/updates/types.bal (1)

112-135: ⚠️ Potential issue | 🔴 Critical

Missing json...; rest descriptor in internal UpdateResponse — will reject upstream fields at runtime.

The upstream service likely still sends fields like jwt, platform-name, platform-version, and product-base-version that were removed from this closed record. Without a json...; rest descriptor (which you did add to RecommendedUpdateLevel, ProductUpdateLevel, UpdateLevel, and the public UpdateResponse in types/types.bal), Ballerina's closed record binding will fail at runtime when the upstream response contains any field not declared here.

🐛 Proposed fix: add `json...;` to accept and discard extra upstream fields

     # Applied update numbers
     int[] applied\-updates\-numbers;
+    json...;
 |};

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/customer-portal/backend/modules/updates/types.bal` around lines 112 -
135, The internal record type UpdateResponse is a closed record and will reject
unexpected upstream fields; add a json rest descriptor to the record body (i.e.,
include json...; inside the UpdateResponse record) so that extra fields like
jwt, platform-name, platform-version, product-base-version are accepted and
discarded at runtime—mirror the same change you already applied to
RecommendedUpdateLevel, ProductUpdateLevel, UpdateLevel, and the public
UpdateResponse in types/types.bal.

🧹 Nitpick comments (1)

apps/customer-portal/backend/service.bal (1)

1323-1330: Include the vulnerability id in the log message for easier debugging.

The current log message references the user but not which vulnerability was requested. Adding the id will make it much easier to trace specific 404 issues.

🔧 Proposed fix

             if getStatusCode(response) == http:STATUS_NOT_FOUND {
-                log:printWarn(string `Requested product vulnerability is not found for the user: ${userInfo.userId}`);
+                log:printWarn(string `Product vulnerability with ID: ${id} is not found for the user: ${userInfo.userId}`);
                 return <http:NotFound>{
                     body: {
                         message: "Requested product vulnerability is not found!"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/customer-portal/backend/service.bal` around lines 1323 - 1330, The 404
log prints the user but not which vulnerability was requested; update the log
inside the getStatusCode(response) == http:STATUS_NOT_FOUND branch to include
the vulnerability identifier (the same variable used to fetch the resource—e.g.,
id or productVulnerabilityId) alongside userInfo.userId by expanding the
template string (e.g., `Requested product vulnerability id ${id} for user
${userInfo.userId} is not found`), ensuring you reference the actual identifier
variable in scope where getStatusCode(response) is checked.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@apps/customer-portal/backend/modules/updates/types.bal`:
- Around line 112-135: The internal record type UpdateResponse is a closed
record and will reject unexpected upstream fields; add a json rest descriptor to
the record body (i.e., include json...; inside the UpdateResponse record) so
that extra fields like jwt, platform-name, platform-version,
product-base-version are accepted and discarded at runtime—mirror the same
change you already applied to RecommendedUpdateLevel, ProductUpdateLevel,
UpdateLevel, and the public UpdateResponse in types/types.bal.

---

Nitpick comments:
In `@apps/customer-portal/backend/service.bal`:
- Around line 1323-1330: The 404 log prints the user but not which vulnerability
was requested; update the log inside the getStatusCode(response) ==
http:STATUS_NOT_FOUND branch to include the vulnerability identifier (the same
variable used to fetch the resource—e.g., id or productVulnerabilityId)
alongside userInfo.userId by expanding the template string (e.g., `Requested
product vulnerability id ${id} for user ${userInfo.userId} is not found`),
ensuring you reference the actual identifier variable in scope where
getStatusCode(response) is checked.