[Customer Portal][BE] Add updates endpoints

[Rashmika998]

Description

This PR adds backend endpoints to support the Updates feature in the Customer Portal, aligned with the existing Support Portal APIs.

The implementation follows the same request/response patterns, validations, and filtering behavior used in the Support Portal to ensure consistency.

All payloads are validated using constraints matching the existing updates invoker endpoints.

---

Endpoints Added

• POST /updates
• GET /updates/recommended-update-levels
• POST /updates/search
• GET /updates/product-update-levels

---

Changes Introduced

• Implemented Updates-related APIs for Product Updates and My Updates.
• Aligned endpoint behavior with existing Support Portal APIs.
• Integrated request payload validation using constraints.
• Applied the same validation rules as updates invoker endpoints.

---

Scope

• Supports retrieving and searching updates.
• Enforces request validation using constraints.
• Ensures authorization and access control.
• Maintains consistency with Support Portal implementation.

---

Related Issues

• [BE] Implement Product Updates APIs #97

---

Notes

• Payload validation logic mirrors existing invoker endpoints.
• Any future changes should remain aligned with Support Portal APIs.

Summary by CodeRabbit

• New Features
  • Added three new updates API endpoints to the customer portal backend: fetch recommended update levels for products, search and list available updates, and retrieve product update level information.
  • Integrated OAuth2 authentication with retry logic for updates service calls.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Introduces a complete updates module integration into the customer portal backend, including HTTP client configuration with OAuth2 authentication and retry logic, comprehensive data types for updates-related information, three service functions for updates operations, and three new REST endpoints for fetching recommended update levels, searching updates, and retrieving product update levels.

Changes

Cohort / File(s)	Summary
Updates Module HTTP Client apps/customer-portal/backend/modules/updates/client.bal	Configures HTTP client with OAuth2 credentials, timeout, HTTP 1.1 protocol, connection pooling (KEEPALIVE_NEVER), and retry logic on transient errors (408, 502, 503, 504).
Updates Data Types apps/customer-portal/backend/modules/updates/types.bal	Defines 10 record types modeling OAuth2 config, product info, file changes, update responses, and update levels to structure updates domain data.
Updates Service Functions apps/customer-portal/backend/modules/updates/updates.bal	Adds three isolated functions: getRecommendedUpdateLevels(), listUpdates(), and getProductUpdateLevels() that delegate to the updates HTTP client.
Updates Utility Helper apps/customer-portal/backend/modules/updates/utils.bal	Introduces generateHeaders() to create JWT assertion headers for authenticated requests to the updates service.
Service Endpoint Integration apps/customer-portal/backend/service.bal	Exposes three new REST endpoints (GET/POST under /updates/*) that extract user context and delegate to the updates module; includes error handling.
Utility Function Modification apps/customer-portal/backend/utils.bal	Updates isInvalidLimitOffset() function signature to include isolated modifier for improved concurrency safety.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• [BE] Implement Product Updates APIs #97 — PR directly implements the backend Updates APIs (client configuration, type definitions, and service endpoints) for the product updates feature integration.

Suggested labels

Type/Improvement

Suggested reviewers

• cloby99
• shayanmalinda

Poem

🐰 Updates flow with JWT in hand,
Retry logic, oh so grand!
OAuth2 guards the way,
New endpoints shine today,
Product knowledge across the land! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description covers purpose, goals, approach, scope, and related issues, but is missing several required template sections like user stories, release notes, documentation, testing details, security checks, and test environment information.	Complete the PR description by adding user stories, release notes, documentation links, test coverage details (unit and integration), security checks confirmation, and test environment specifications as required by the template.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title '[Customer Portal][BE] Add updates endpoints' directly and accurately describes the main change—adding updates endpoints to the Customer Portal backend.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ 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]

Actionable comments posted: 5

🤖 Fix all issues with AI agents

In `@apps/customer-portal/backend/modules/updates/client.bal`:
- Around line 22-40: The shared HTTP client updatesClient is configured to retry
on http:STATUS_INTERNAL_SERVER_ERROR which is risky for non-idempotent
operations like addUpdate (POST /updates); modify the retryConfig on
updatesClient by removing http:STATUS_INTERNAL_SERVER_ERROR from statusCodes (or
create a separate client/config for the write path used by addUpdate with 500
excluded) and add a backOffFactor (e.g., 2.0) to retryConfig to implement
exponential backoff instead of a constant 2.0s interval.

In `@apps/customer-portal/backend/modules/updates/types.bal`:
- Around line 30-75: The UpdateDescription type's updateLevel field lacks the
same validation as UpdatesPayload.updateLevel, allowing invalid values through
updateDescriptions; locate the UpdateDescription definition and add the same
integer constraint annotation (`@constraint`:Int {minValue: 1}) to the updateLevel
field so each nested UpdateDescription enforces updateLevel >= 1, matching the
invariant enforced by UpdatesPayload.updateLevel.

In `@apps/customer-portal/backend/modules/updates/updates.bal`:
- Around line 61-71: The getProductUpdateLevels function uses two different
request paths depending on updateLevelState:
updatesClient->/product-update-levels.get(...) when updateLevelState is present
and updatesClient->/updates/product-update-levels.get(...) when nil; make them
consistent by using the correct base path (e.g.,
/updates/product-update-levels.get) in both branches, keeping the same
generateHeaders(idToken) call and the updateLevelState parameter
(updateLevelState = updateLevelStateToUse) in the branch that supplies it so
both calls target the same endpoint.

In `@apps/customer-portal/backend/service.bal`:
- Around line 974-977: Fix the typo in the doc comment for the "Get product
update levels" block: change the word "Lost" to "List" in the return description
(the line that currently reads "# + return - Lost of product update levels or an
error"); update the comment near "updateLevelState" so the return line reads "#
+ return - List of product update levels or an error" to accurately describe the
return value.
- Around line 885-913: The POST updates resource (resource function post
updates) currently converts all errors from updates:addUpdate into a generic
500; change it to inspect the upstream error for STATUS_UNAUTHORIZED and
STATUS_FORBIDDEN (same pattern used by projects/cases/comments/attachments) and
return http:Unauthorized and http:Forbidden respectively, else log and return
http:InternalServerError; also update the function return type union to include
http:Unauthorized|http:Forbidden so callers get proper 401/403 responses.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apps/customer-portal/backend/modules/updates/updates.bal`:
- Around line 30-32: In listUpdates, the call to
updatesClient->/updates/list-updates.post passes headers positionally; change it
to pass headers as a named argument (use headers = generateHeaders(idToken))
while keeping readOnly = true so
updateClient->/updates/list-updates.post(payload, headers =
generateHeaders(idToken), readOnly = true) is used; locate this in the public
isolated function listUpdates and update the call that currently references
generateHeaders(idToken).

🧹 Nitpick comments (1)

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

82-93: Document the security model for forwarding upstream jwtToken to the portal client.

BasicFileInfo exposes a jwtToken field that originates from the upstream updates service and is forwarded directly in the HTTP response to the portal frontend. This design appears intentional—the tokens enable client-side downloads of update files via the provided downloadUrl. However, the security posture depends entirely on the upstream service's token generation and scope. Consider adding documentation clarifying:

• The intended scope and lifetime of these tokens
• Whether they grant access only to update files or have broader permissions
• Any security assumptions about the downstream update service

This ensures future maintainers understand the security model behind this forwarding pattern.