Provision missing subscription plans on the API Portal during API publish

[Pranavan-S]

Purpose

When an API is published to the API Portal, its draft can select subscription plans. The portal may not have those plans yet, so the publish will fail. Additionally, the inactive plans should be filtered out from publishing to api-portal.

Goals

• Make sure the portal has every plan the draft selects before the API is published.
• Reject unknown and inactive plans early with a clear validation error.

Approach

• Publish now lists the plans the portal already has, matches them by exact handle, and creates only the missing ones in one bulk request. This runs before the listing is pushed.
• If the portal rejects a plan, publish stops and returns 409.
• Draft save and publish now check that each selected plan exists in the organization and is active, and return 400 otherwise.

User stories

• As a publisher, I can publish an API with subscription plans without first creating the plans on the portal by hand.
• As a publisher, I get a clear error when I select a plan that does not exist or is not active.

Documentation

N/A

Automation tests

• Unit tests

  New tests for the portal plan listing and bulk create client.

• Integration tests

  New cases for plans created before the push, no plan step when no plans are selected, plan failure stopping the publish, inactive plan rejected on draft save, and plan deactivated after save rejected on publish. All SQLite integration tests pass.

Security checks

• Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes/no
• Ran FindSecurityBugs plugin and verified report? yes/no
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes/no

Samples

N/A

Related PRs

Follows the API Portal subscription plan fixes in #3679 .

Test environment

macOS, SQLite for integration tests, plus manual checks in the browser against a local API Portal.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: wso2/api-platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: e52a0676-04d4-40a2-90b0-0f536b6676ff

📥 Commits

Reviewing files that changed from the base of the PR and between 4d62532 and fba0137.

📒 Files selected for processing (5)

• platform-api/internal/repository/subscription_plan_repository.go
• platform-api/internal/repository/subscription_plan_test.go
• platform-api/internal/service/publication.go
• platform-api/internal/service/publication_plans_test.go
• platform-api/internal/service/publication_validation_test.go

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The publication service now validates selected plans as active and creates plans missing from the API Portal before publishing. The change adds paginated portal plan lookup, bulk plan creation, error handling, tests, and updated API error descriptions.

Changes

Publication Plan Synchronization

Layer / File(s)	Summary
Load and validate subscription plans platform-api/internal/repository/interfaces.go, platform-api/internal/repository/subscription_plan_repository.go, platform-api/internal/repository/subscription_plan_test.go, platform-api/internal/service/publication.go, platform-api/internal/service/publication_plans_test.go, platform-api/internal/service/publication_validation_test.go	The repository loads full plans by handle and organization. Publication validation rejects unknown or inactive plans and preserves the requested handle order when resolving UUIDs. Document-handle validation reports unresolved handles.
List and create API Portal plans platform-api/internal/service/portal_publisher.go, platform-api/internal/service/http_portal_publisher.go, platform-api/internal/service/http_portal_plans.go, platform-api/internal/service/http_portal_plans_test.go, platform-api/internal/service/http_portal_publisher_test.go	The portal publisher lists plans by exact handle and creates only missing plans. Tests cover pagination, payload mapping, and error responses.
Synchronize plans before publication platform-api/internal/service/publication.go, platform-api/internal/integration/api_publication_plans_test.go, platform-api/internal/integration/api_publication_test.go, platform-api/internal/handler/api_publication_integration_test.go, platform-api/resources/openapi.yaml	Publication synchronizes selected plans before publishing, with a 25-second timeout. Tests cover skipped synchronization, failure handling, call order, inactive plans, and draft retention. The OpenAPI descriptions cover inactive-plan failures and portal conflicts.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant PublicationService
  participant HTTPPortalPublisher
  participant APIPortal
  PublicationService->>HTTPPortalPublisher: CreateMissingPlans for selected active plans
  HTTPPortalPublisher->>APIPortal: List subscription plans by page
  APIPortal-->>HTTPPortalPublisher: Return listed plans
  HTTPPortalPublisher->>APIPortal: Create missing plans
  APIPortal-->>HTTPPortalPublisher: Return creation response
  HTTPPortalPublisher-->>PublicationService: Return synchronization result
  PublicationService->>HTTPPortalPublisher: Publish after successful synchronization

Loading

Merge Risk: ⚪ Minimal · up to fba01

Publishing now checks that selected plans are active and creates any plans the API Portal is missing before it publishes. Tests cover the main failure paths, and no merge-blocking issue was found in the supplied context.

Security Architecture Review

Security architecture risk: 🔵 Low · up to fba01

Selected plans remain restricted to the publisher’s organization, and inactive plans are now rejected. The main design risk is recovery: portal plans can remain after publication fails, and interrupted or concurrent creation depends on the portal’s duplicate-handling guarantees.

Retained concerns

• Low · architecture · observed: New shared catalog writes can survive failed publication. A successful plan-create request followed by portal publication or local promotion failure leaves the portal plans in place without compensation. This expands the pre-existing portal-first consistency window beyond an individual API listing. Sequential re-listing supports recovery, but interrupted and concurrent creation still rely on unverified remote duplicate and atomicity guarantees.

Security review details

Security Blast Radius

• inferred — The examined local boundary restricts selectable APIs, portals and plans to the request organization. The new mutation targets the selected portal’s plan collection, so its persistence extends beyond one API listing. Remote tenant isolation and credential privilege scope were not established by the available client-side evidence.

Trust Boundaries and Controls

• observed — Caller-controlled draft handles cross into an organization-bound repository query using bound parameters. The draft handler obtains organization identity from request middleware rather than the payload, and portal authentication is separately resolved for the selected organization and portal.

Resilience and Maintainability Implications

• observed — The unchanged HTTP client can rewind and replay request bodies after network errors or 5xx responses. The new plan-create POST uses a rewindable body without an idempotency key, making safe recovery dependent on portal duplicate handling. This is a newly exercised mutation, not a newly introduced retry policy.

Hardening Proposals

• proposed — Define portal catalog ownership and recovery guarantees for duplicate creates, concurrent publication and responses lost after commit. Prefer an idempotent create or authoritative reconciliation path; avoid automatic deletion of plans that may be shared by other API listings.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 40 functions across 14 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: provisioning missing subscription plans on the API Portal during API publication.
Description check	✅ Passed	The description covers the purpose, goals, approach, user stories, documentation impact, tests, related work, and test environment. The security-check questions remain unanswered, and the test environ…

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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

[codecov-commenter]

Codecov Report

❌ Patch coverage is 87.91946% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 58.91%. Comparing base (4b76b30) to head (fba0137).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
platform-api/internal/service/http_portal_plans.go	84.94%	7 Missing and 7 partials ⚠️
platform-api/internal/service/publication.go	93.18%	3 Missing ⚠️
...nternal/repository/subscription_plan_repository.go	90.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3685      +/-   ##
==========================================
+ Coverage   54.95%   58.91%   +3.96%     
==========================================
  Files         931      943      +12     
  Lines      150505   151565    +1060     
  Branches     4809     4809              
==========================================
+ Hits        82716    89301    +6585     
+ Misses      61511    55227    -6284     
- Partials     6278     7037     +759     

Flag	Coverage Δ
ai-workspace-bff-integration	9.78% <ø> (-4.13%)	⬇️
ai-workspace-bff-unit	82.73% <ø> (-1.89%)	⬇️
ai-workspace-ui-integration	24.99% <ø> (ø)
api-portal-server-integration	57.98% <ø> (ø)
api-portal-server-it	67.84% <ø> (-0.04%)	⬇️
api-portal-ui-integration	29.26% <ø> (+0.01%)	⬆️
api-portal-unit	60.36% <ø> (+0.92%)	⬆️
gateway-controller-integration	50.22% <ø> (+25.35%)	⬆️
gateway-controller-unit	53.21% <ø> (ø)
platform-api-integration	42.09% <0.00%> (+16.64%)	⬆️
platform-api-unit	35.56% <87.91%> (+0.76%)	⬆️
policy-engine-integration	41.82% <ø> (+19.62%)	⬆️
policy-engine-unit	60.42% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.