[API Platform] Update OpenAPI documentation and refactor according to rest api guidelines#2308
Closed
Thushani-Jayasekera wants to merge 6 commits into
Closed
[API Platform] Update OpenAPI documentation and refactor according to rest api guidelines#2308Thushani-Jayasekera wants to merge 6 commits into
Thushani-Jayasekera wants to merge 6 commits into
Conversation
…or consistency across various handlers. Update related comments and routes in the platform API to reflect this change, enhancing clarity and maintainability.
…handle' in various API calls and adjust related logic. Add 'api-reports/' to .gitignore to exclude report files from version control.
Thushani-Jayasekera
requested review from
AnuGayan,
Arshardh,
CrowleyRajapakse,
HeshanSudarshana,
HiranyaKavishani,
Krishanx92,
PasanT9,
RakhithaRR,
Tharsanan1,
VirajSalaka,
ashera96,
chamilaadhi,
dushaniw,
hisanhunais,
malinthaprasan,
pubudu538,
renuka-fernando,
senthuran16,
tgtshanika,
tharikaGitHub and
tharindu1st
as code owners
June 27, 2026 15:17
Contributor
📝 WalkthroughWalkthroughThe PR updates REST, WebSub, WebBroker, LLM, MCP, gateway, application, secret, and subscription-plan APIs to use handle-based paths, request fields, and service lookups. It also changes generated contracts and OpenAPI definitions, updates portal API clients and UI state to track gateway/API handles, adds API uniqueness validation, and adjusts deployment URL shapes for undeploy/restore operations. Suggested Reviewers
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 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}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 18
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
platform-api/src/internal/handler/llm.go (1)
157-176: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winRename the remaining
idwording in these handle-based handlers.These endpoints now expose
templateHandle,providerHandle, andproxyHandle, but several 400 responses and log labels still sayid. Updating them tohandle(or a neutralidentifier) would keep the API surface and diagnostics consistent with the renamed routes.Also applies to: 183-214, 261-281, 369-397, 406-431, 514-533, 582-604, 699-734, 741-760, 806-828
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/llm.go` around lines 157 - 176, The remaining “id” wording in the handle-based endpoint handlers is inconsistent with the renamed route params. Update the affected handlers, especially GetLLMProviderTemplate and the similar Get*/Delete* methods elsewhere in this file, so 400 responses and slogger labels use “handle” or a neutral “identifier” instead of “id”. Keep the parameter variables like templateHandle/providerHandle/proxyHandle aligned with the response text and log keys.portals/management-portal/src/hooks/deployments.ts (1)
54-69: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
revisionIdis no longer sent in the deploy request.Line 57 is still part of the hook contract, but the new POST only sends
targets. That drops the selected revision from the request, so deploy calls can target the wrong revision or fail. Keep serializingrevisionIduntil the backend contract and this hook signature are updated together.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/management-portal/src/hooks/deployments.ts` around lines 54 - 69, The deployRevision hook still accepts revisionId in its contract, but the POST body in deployRevision no longer includes it, so deployments can lose the selected revision. Update the request payload in deployRevision to serialize revisionId together with targets, and keep the hook signature aligned with the backend contract until both are changed together.portals/management-portal/src/context/ApiContext.tsx (1)
223-239: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winApply the same handle-aware matching to the rest of the delete cleanup.
Line 223 now treats
apiIdas either anidor ahandle, but Lines 231-239 still cleargatewaysByApiandcurrentApiIdRefby exact string equality only. Deleting by handle can leave stale gateway data and keep the deleted API selected. Reuse the same identifier-matching rule for all delete-side cleanup.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/management-portal/src/context/ApiContext.tsx` around lines 223 - 239, The delete cleanup in ApiContext should use the same id-or-handle matching as the items filter, not only exact apiId equality. Update the gateway cache removal and the currentApiIdRef/selectApi cleanup in the delete flow to resolve the deleted API by either its id or handle, so deleting via handle also clears gateways and deselects the deleted API. Keep the matching logic consistent with the existing filter in the same delete handler.portals/management-portal/src/hooks/apis.ts (1)
256-277: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winEncode the API identifier in these path segments.
Lines 256 and 277 interpolate
apiIddirectly, while the gateway routes in this same hook already useencodeURIComponent. With handle-based identifiers, fetch/delete can break for valid API keys that contain reserved characters. Encode the path segment here too.Proposed fix
- const response = await fetch(`${baseUrl}/api/v0.9/rest-apis/${apiId}`, { + const response = await fetch(`${baseUrl}/api/v0.9/rest-apis/${encodeURIComponent(apiId)}`, { ... - const response = await fetch(`${baseUrl}/api/v0.9/rest-apis/${apiId}`, { + const response = await fetch(`${baseUrl}/api/v0.9/rest-apis/${encodeURIComponent(apiId)}`, {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/management-portal/src/hooks/apis.ts` around lines 256 - 277, The fetchApi and deleteApi requests in apis.ts interpolate apiId directly into the REST path, which can break for handle-based IDs with reserved characters. Update the URL construction in both useCallback handlers to encode apiId as a path segment, matching the existing gateway route handling in this hook and preserving the current error handling and response parsing.portals/management-portal/src/pages/apis/ApiOverview.tsx (1)
759-770: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winBuild the publish query with
URLSearchParams.This branch now passes
api.handle ?? api.id, but it concatenates the query string manually. If that identifier needs escaping, the publish page receives the wrongapiId. Construct the query the same way as the Deploy button below.Proposed fix
- navigate(`${base}?apiId=${api.handle ?? api.id}`); + const params = new URLSearchParams(); + params.set("apiId", api.handle ?? api.id); + navigate(`${base}?${params.toString()}`);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/management-portal/src/pages/apis/ApiOverview.tsx` around lines 759 - 770, The publish navigation in ApiOverview’s Button onClick handler builds the apiId query string manually, which can break when the identifier needs escaping. Update the navigation logic to construct the query with URLSearchParams, matching the Deploy button’s approach, and then append the serialized params to the publish base path before calling navigate.platform-api/src/resources/openapi.yaml (1)
589-674: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winFinish the UUID→handle documentation update.
These routes and the shared
gatewayHandlequery parameter still describe UUID-based lookup even though the contract now takes handles. That makes the published API docs inconsistent with the backend behavior.Also applies to: 4462-4476, 11149-11156
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/resources/openapi.yaml` around lines 589 - 674, Update the REST API documentation to describe handle-based lookup instead of UUID-based lookup. In the /rest-apis/{apiHandle} paths and the shared gatewayHandle/apiHandle parameter definitions, change the summary/description text to refer to handles consistently so the OpenAPI contract matches the backend behavior. Keep the same operations and schemas, but ensure any UUID wording in GetRESTAPI, UpdateRESTAPI, DeleteRESTAPI, and the shared parameter docs is replaced with handle terminology.
🧹 Nitpick comments (3)
.agents/skills/rest-api-oauth-scopes/SKILL.md (1)
74-74: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueClarify the new guideline to avoid contradiction with explicit custom-verb examples.
The new bullet advises preferring "existing domain nouns + standard verbs over custom-verb paths," yet the same section explicitly demonstrates and relies on custom-verb paths (
/set-default,/import-openapi,/validate-openapi) and Rule 3 allows genuine custom verbs. Without concrete examples of what this preference looks like in practice, readers may be unsure when custom verbs are acceptable versus discouraged.Consider adding a brief contrasting example or qualifying clause that distinguishes discouraged invented verbs from the allowed genuine lifecycle verbs listed in Rule 3.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.agents/skills/rest-api-oauth-scopes/SKILL.md at line 74, Clarify the “Prefer existing domain nouns + standard verbs over custom-verb paths” guideline in SKILL.md so it does not seem to contradict the custom-verb examples and Rule 3. Update that bullet to distinguish discouraged invented verbs from allowed genuine lifecycle verbs, and add a brief contrasting example near the existing /set-default, /import-openapi, and /validate-openapi references to show when custom verbs are acceptable versus avoided.platform-api/src/internal/handler/subscription_plan_handler.go (1)
249-253: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
Warnfor invalid request bodies.This path returns 400, so log it at
Warninstead ofError.Proposed change
- h.slogger.Error("Invalid update subscription plan request body", "planHandle", planHandle, "organizationId", orgId, "error", err) + h.slogger.Warn("Invalid update subscription plan request body", "planHandle", planHandle, "organizationId", orgId, "error", err)Based on learnings, expected 4xx handler errors should use
slog.Warn, reservingslog.Errorfor unexpected 5xx failures.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/subscription_plan_handler.go` around lines 249 - 253, The invalid JSON body path in UpdateSubscriptionPlan should be logged at warning level, not error level. Update the logging call in the ShouldBindJSON failure branch of subscription_plan_handler.go (the handler around UpdateSubscriptionPlanRequest) to use h.slogger.Warn instead of h.slogger.Error, keeping the existing context fields like planHandle and orgId.Source: Learnings
platform-api/src/internal/handler/mcp.go (1)
135-138: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
Warnfor these 401 branches.These are expected client-side failures, so logging them as errors will add noise to server-error signals.
Warnis the better fit here. Based on learnings, handlers underplatform-api/src/internal/handlershould useslog.Warnfor expected 4xx responses and reserveslog.Errorfor unexpected 5xx failures.Suggested change
- h.slogger.Error("MCP request validation failed", "reason", "Organization claim not found in token") + h.slogger.Warn("MCP request validation failed", "reason", "Organization claim not found in token")Also applies to: 154-157, 181-184
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/mcp.go` around lines 135 - 138, The 401 branches in MCP handler are expected client-side failures, so change the logging in the relevant paths of mcp.go to use h.slogger.Warn instead of h.slogger.Error. Update the unauthorized branches around middleware.GetOrganizationFromContext and the other matching 4xx checks in the same handler so only unexpected 5xx cases remain as errors.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@platform-api/src/api/generated.go`:
- Around line 2846-2848: The generated SubscriptionPlan model is out of sync
because it still exposes PlanName even though the schema now only uses handle
and name. Regenerate the OpenAPI output for SubscriptionPlan in generated.go so
the struct fields and any related serialization logic match the current
contract, and ensure only the remaining properties are present in the model.
In `@platform-api/src/internal/handler/api_deployment.go`:
- Line 57: Update the deployment handler terminology to match the new route
contract that uses apiHandle instead of apiId. In api_deployment.go, rename the
local variable and any related diagnostics in the touched handler blocks so they
use apiHandle consistently, and replace remaining “API ID” response/log text
with “API handle” (or equivalent) in the affected deployment methods to keep
errors and logs aligned with c.Param("apiHandle").
In `@platform-api/src/internal/handler/api.go`:
- Around line 867-873: The route table in apiGroup setup is missing the new REST
API uniqueness validation endpoint, so the validation hook has nothing to hit.
Add a matching GET route for the REST API validation path alongside the existing
GetAPI/ImportOpenAPI/ValidateOpenAPI registrations, and wire it to the
appropriate handler in this api.go handler setup so `validation.ts` can call
`GET /api/v0.9/rest-apis/validate` successfully.
- Line 180: The touched handler blocks still use outdated API ID wording even
though they now read the route param via apiHandle. Update the adjacent 400
response messages and log fields in the affected handler functions in api.go to
use consistent apiHandle/api handle terminology instead of API ID/apiId, keeping
the request parameter name, error text, and diagnostics aligned with the new
contract.
In `@platform-api/src/internal/handler/gateway.go`:
- Around line 175-179: Update the handle-route validation text in gateway.go so
the comments and 400 responses consistently use gatewayHandle instead of stale
ID/UUID/gatewayId wording. In the gateway handler paths that read
c.Param("gatewayHandle"), revise the nearby comments and any
utils.NewErrorResponse messages to match the new REST contract, keeping the
user-facing error text aligned across the affected handler blocks in the gateway
methods.
In `@platform-api/src/internal/handler/llm_deployment.go`:
- Around line 66-69: The 400 response messages in the provider/proxy validation
branches still use “ID is required” even though the route now uses handle
terminology. Update the error text in the relevant checks around the
providerHandle and proxyHandle validation paths in llm_deployment.go, and apply
the same wording change anywhere the same response pattern appears so the
returned message says the handle is required instead of the ID.
In `@platform-api/src/internal/handler/llm_proxy_apikey.go`:
- Around line 57-60: Update the 400 validation messages in the LLM proxy API
handlers to refer to proxyHandle instead of proxy ID. In llm_proxy_apikey.go,
adjust the empty-parameter checks in the relevant handler functions (the ones
using c.Param("proxyHandle")) so the error text matches the route’s handle-based
naming consistently across the listed sections.
In `@platform-api/src/internal/handler/mcp_deployment.go`:
- Around line 73-76: The 400 validation messages in mcp_deployment.go still say
“ID” even though the handler uses the mcpProxyHandle route parameter. Update the
error text in the affected handler branches to say “handle” instead of “ID” so
the responses match the contract. Apply this consistently in the validation
logic around proxyId in the relevant handler functions, including the repeated
checks called out in the comment.
In `@platform-api/src/internal/handler/webbroker_api_deployment.go`:
- Around line 64-75: The validation error messages in DeployWebBrokerAPI and the
other affected handler should use handle wording instead of ID wording to match
the :apiHandle route contract. Update the bad-request message where apiHandle is
checked so it says API handle is required (or API identifier is required), and
apply the same wording consistently in the corresponding deployment handler(s)
referenced by the review.
In `@platform-api/src/internal/handler/websub_api_deployment.go`:
- Around line 64-75: The validation error messages in DeployWebSubAPI and the
other apiHandle-based handler should use handle wording instead of API ID.
Update the bad-request response text where c.Param("apiHandle") is validated so
it says “API handle is required” or a neutral “identifier is required,” keeping
the migrated contract consistent for clients. Use the handler names and the
apiHandle parameter lookup as the anchor points when making the change.
In `@platform-api/src/internal/service/gateway.go`:
- Around line 325-328: In gateway.go, the gateway lookup in the service method
using gatewayRepo.GetByHandleAndOrgID currently collapses repository errors and
nil results into the same “gateway not found” response. Split the err check from
the gateway == nil check, following the pattern used by the other service
methods in this package, so real lookup failures are returned as errors while
only a nil gateway becomes “not found”.
In `@platform-api/src/internal/service/subscription_plan_service.go`:
- Around line 66-75: The create/update flow in subscription_plan_service.go
currently only generates a handle when plan.Handle is empty, but it lets any
supplied value pass through unchanged even though it is later used as
/:planHandle. Update the handle-setting logic in the subscription plan service
(around the GenerateHandle path) to validate or normalize any non-empty
plan.Handle before persisting, and reject invalid non-URL-friendly values so
subscription plans remain reliably addressable by handle.
In `@platform-api/src/resources/openapi.yaml`:
- Around line 7538-7549: Keep Gateway.name semantics aligned between the request
and response schemas by updating the Gateway-related OpenAPI definitions so the
same field means the same thing everywhere. Adjust the relevant schema entries
in openapi.yaml for GatewayResponse and CreateGatewayRequest so name and
displayName are consistent, and ensure handle remains the URL-friendly
identifier; if needed, rename or re-document the request field to match the
response contract and avoid divergent meanings for name.
- Around line 8093-8100: The subscription plan `handle` is described as
URL-friendly but is only validated for presence/uniqueness, so update the
`handle` schema in the OpenAPI definitions and the subscription plan
create/update validation logic to enforce the advertised slug format. Use the
existing subscription plan request/response schemas around `handle` and `name`
as the place to add the constraint, and ensure the service code that currently
checks only non-empty/unique values rejects any handle that is not a
slug-compatible identifier.
In `@portals/ai-workspace/src/apis/gateway/gatewayApi.ts`:
- Line 89: The gateway manifest response is now wrapped in a policies envelope,
but the existing consumer in gatewayApi.ts still returns the raw backend shape,
so the configs drawer cannot read the key manager entries. Update the manifest
fetch/normalization path around the gateway API call to unwrap policies before
returning, or adjust the downstream parser to recognize this new envelope
alongside the existing raw/configs/data/items wrappers. Keep the fix localized
to the manifest handling logic and use the existing gatewayApi manifest request
as the entry point.
In `@portals/management-portal/src/context/GatewayContext.tsx`:
- Around line 219-223: The token lifecycle in GatewayContext is using
inconsistent gateway keys, so storage, refresh, rotate, and delete can drift
apart. Add a single gateway-key helper in GatewayContext and use it everywhere
that reads or writes gateway tokens, including the rotateGatewayTokenRequest
flow, the refresh logic, and the delete path. Make sure the helper covers the
same fallback chain for gateway.handle, gateway.name, and gateway.id so token
records are stored, preserved, and removed using one consistent key.
In `@portals/management-portal/src/pages/gateways/GatewayList.tsx`:
- Around line 170-173: The gateway status lookup in GatewayList is using gwKey
even though GatewayContext stores statuses by s.id, so handle-based keys can
miss existing data and show inactive gateways. Update the status resolution in
the GatewayList logic to look up by the stored identifier used by the context
(g.id/s.id), or add a handle fallback so both id and handle-based keys are
covered. Keep the change aligned with the existing getGatewayStatus and
gatewayStatuses access pattern.
In `@portals/management-portal/src/pages/overview/StepHeader.tsx`:
- Line 489: The token cache key is inconsistent between rotation and lookup in
StepHeader, so created-token data can be missed when handle/name differs from
id. Introduce a single gatewayKey derived from handle ?? name ?? id and use it
consistently in rotateGatewayToken and when reading createdToken from
gatewayTokens so the created-gateway summary and copy flow stay in sync.
---
Outside diff comments:
In `@platform-api/src/internal/handler/llm.go`:
- Around line 157-176: The remaining “id” wording in the handle-based endpoint
handlers is inconsistent with the renamed route params. Update the affected
handlers, especially GetLLMProviderTemplate and the similar Get*/Delete* methods
elsewhere in this file, so 400 responses and slogger labels use “handle” or a
neutral “identifier” instead of “id”. Keep the parameter variables like
templateHandle/providerHandle/proxyHandle aligned with the response text and log
keys.
In `@platform-api/src/resources/openapi.yaml`:
- Around line 589-674: Update the REST API documentation to describe
handle-based lookup instead of UUID-based lookup. In the /rest-apis/{apiHandle}
paths and the shared gatewayHandle/apiHandle parameter definitions, change the
summary/description text to refer to handles consistently so the OpenAPI
contract matches the backend behavior. Keep the same operations and schemas, but
ensure any UUID wording in GetRESTAPI, UpdateRESTAPI, DeleteRESTAPI, and the
shared parameter docs is replaced with handle terminology.
In `@portals/management-portal/src/context/ApiContext.tsx`:
- Around line 223-239: The delete cleanup in ApiContext should use the same
id-or-handle matching as the items filter, not only exact apiId equality. Update
the gateway cache removal and the currentApiIdRef/selectApi cleanup in the
delete flow to resolve the deleted API by either its id or handle, so deleting
via handle also clears gateways and deselects the deleted API. Keep the matching
logic consistent with the existing filter in the same delete handler.
In `@portals/management-portal/src/hooks/apis.ts`:
- Around line 256-277: The fetchApi and deleteApi requests in apis.ts
interpolate apiId directly into the REST path, which can break for handle-based
IDs with reserved characters. Update the URL construction in both useCallback
handlers to encode apiId as a path segment, matching the existing gateway route
handling in this hook and preserving the current error handling and response
parsing.
In `@portals/management-portal/src/hooks/deployments.ts`:
- Around line 54-69: The deployRevision hook still accepts revisionId in its
contract, but the POST body in deployRevision no longer includes it, so
deployments can lose the selected revision. Update the request payload in
deployRevision to serialize revisionId together with targets, and keep the hook
signature aligned with the backend contract until both are changed together.
In `@portals/management-portal/src/pages/apis/ApiOverview.tsx`:
- Around line 759-770: The publish navigation in ApiOverview’s Button onClick
handler builds the apiId query string manually, which can break when the
identifier needs escaping. Update the navigation logic to construct the query
with URLSearchParams, matching the Deploy button’s approach, and then append the
serialized params to the publish base path before calling navigate.
---
Nitpick comments:
In @.agents/skills/rest-api-oauth-scopes/SKILL.md:
- Line 74: Clarify the “Prefer existing domain nouns + standard verbs over
custom-verb paths” guideline in SKILL.md so it does not seem to contradict the
custom-verb examples and Rule 3. Update that bullet to distinguish discouraged
invented verbs from allowed genuine lifecycle verbs, and add a brief contrasting
example near the existing /set-default, /import-openapi, and /validate-openapi
references to show when custom verbs are acceptable versus avoided.
In `@platform-api/src/internal/handler/mcp.go`:
- Around line 135-138: The 401 branches in MCP handler are expected client-side
failures, so change the logging in the relevant paths of mcp.go to use
h.slogger.Warn instead of h.slogger.Error. Update the unauthorized branches
around middleware.GetOrganizationFromContext and the other matching 4xx checks
in the same handler so only unexpected 5xx cases remain as errors.
In `@platform-api/src/internal/handler/subscription_plan_handler.go`:
- Around line 249-253: The invalid JSON body path in UpdateSubscriptionPlan
should be logged at warning level, not error level. Update the logging call in
the ShouldBindJSON failure branch of subscription_plan_handler.go (the handler
around UpdateSubscriptionPlanRequest) to use h.slogger.Warn instead of
h.slogger.Error, keeping the existing context fields like planHandle and orgId.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 27d122f9-22ef-4020-b94a-ec47bab72196
📒 Files selected for processing (42)
.agents/skills/rest-api-oauth-scopes/SKILL.md.gitignoreplatform-api/src/api/generated.goplatform-api/src/internal/handler/api.goplatform-api/src/internal/handler/api_deployment.goplatform-api/src/internal/handler/api_key.goplatform-api/src/internal/handler/application.goplatform-api/src/internal/handler/gateway.goplatform-api/src/internal/handler/llm.goplatform-api/src/internal/handler/llm_apikey.goplatform-api/src/internal/handler/llm_deployment.goplatform-api/src/internal/handler/llm_proxy_apikey.goplatform-api/src/internal/handler/mcp.goplatform-api/src/internal/handler/mcp_deployment.goplatform-api/src/internal/handler/subscription_plan_handler.goplatform-api/src/internal/handler/webbroker_api.goplatform-api/src/internal/handler/webbroker_api_deployment.goplatform-api/src/internal/handler/webbroker_apikey.goplatform-api/src/internal/handler/websub_api.goplatform-api/src/internal/handler/websub_api_deployment.goplatform-api/src/internal/handler/websub_api_hmac_secret.goplatform-api/src/internal/handler/websub_apikey.goplatform-api/src/internal/service/gateway.goplatform-api/src/internal/service/subscription_plan_service.goplatform-api/src/resources/openapi.yamlportals/ai-workspace/src/apis/MCP/mcpServerDeployApis.tsportals/ai-workspace/src/apis/gateway/gatewayApi.tsportals/ai-workspace/src/apis/gateway/types.tsportals/ai-workspace/src/apis/llmProviderApis.tsportals/ai-workspace/src/apis/llmProxiesApis.tsportals/ai-workspace/src/pages/appShell/appShellPages/gateways/ViewGateway.tsxportals/management-portal/src/context/ApiContext.tsxportals/management-portal/src/context/GatewayContext.tsxportals/management-portal/src/hooks/apiPublish.tsportals/management-portal/src/hooks/apis.tsportals/management-portal/src/hooks/deployments.tsportals/management-portal/src/hooks/gateways.tsportals/management-portal/src/hooks/validation.tsportals/management-portal/src/pages/Gateway.tsxportals/management-portal/src/pages/apis/ApiOverview.tsxportals/management-portal/src/pages/gateways/GatewayList.tsxportals/management-portal/src/pages/overview/StepHeader.tsx
Comment on lines
+2846
to
+2848
| Handle *string `json:"handle,omitempty" yaml:"handle,omitempty"` | ||
| Id *openapi_types.UUID `json:"id,omitempty" yaml:"id,omitempty"` | ||
| Name *string `json:"name,omitempty" yaml:"name,omitempty"` |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Regenerate SubscriptionPlan after removing planName.
The generated model still exposes PlanName at Line 2850, but the updated schema/runtime contract only publishes handle and name. That leaves generated.go out of sync with platform-api/src/resources/openapi.yaml and the handler response shape.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/api/generated.go` around lines 2846 - 2848, The generated
SubscriptionPlan model is out of sync because it still exposes PlanName even
though the schema now only uses handle and name. Regenerate the OpenAPI output
for SubscriptionPlan in generated.go so the struct fields and any related
serialization logic match the current contract, and ensure only the remaining
properties are present in the model.
| } | ||
|
|
||
| apiId := c.Param("apiId") | ||
| apiId := c.Param("apiHandle") |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Align deployment handler diagnostics with apiHandle.
These endpoints now read :apiHandle, but the touched blocks still carry apiId naming and API ID response text around them. Updating the remaining terminology here will keep deployment errors and logs consistent with the new route contract.
Also applies to: 146-146, 219-219, 283-283, 333-333, 378-378
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/internal/handler/api_deployment.go` at line 57, Update the
deployment handler terminology to match the new route contract that uses
apiHandle instead of apiId. In api_deployment.go, rename the local variable and
any related diagnostics in the touched handler blocks so they use apiHandle
consistently, and replace remaining “API ID” response/log text with “API handle”
(or equivalent) in the affected deployment methods to keep errors and logs
aligned with c.Param("apiHandle").
| } | ||
|
|
||
| apiId := c.Param("apiId") | ||
| apiId := c.Param("apiHandle") |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Update the remaining API ID terminology in these handlers.
These routes now bind :apiHandle, but the adjacent 400 responses and log fields in each touched block still refer to API ID/apiId. That leaves client errors and diagnostics inconsistent with the new contract.
Also applies to: 260-260, 335-335, 372-372, 429-429
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/internal/handler/api.go` at line 180, The touched handler
blocks still use outdated API ID wording even though they now read the route
param via apiHandle. Update the adjacent 400 response messages and log fields in
the affected handler functions in api.go to use consistent apiHandle/api handle
terminology instead of API ID/apiId, keeping the request parameter name, error
text, and diagnostics aligned with the new contract.
Comment on lines
+867
to
+873
| apiGroup.GET("/:apiHandle", h.GetAPI) | ||
| apiGroup.PUT("/:apiHandle", h.UpdateAPI) | ||
| apiGroup.DELETE("/:apiHandle", h.DeleteAPI) | ||
| apiGroup.POST("/import-openapi", h.ImportOpenAPI) | ||
| apiGroup.POST("/validate-openapi", h.ValidateOpenAPI) | ||
| apiGroup.GET("/:apiId/gateways", h.GetAPIGateways) | ||
| apiGroup.POST("/:apiId/gateways", h.AddGatewaysToAPI) | ||
| apiGroup.GET("/:apiHandle/gateways", h.GetAPIGateways) | ||
| apiGroup.POST("/:apiHandle/gateways", h.AddGatewaysToAPI) |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Register the new REST API uniqueness validation route as well.
portals/management-portal/src/hooks/validation.ts now calls GET /api/v0.9/rest-apis/validate?..., but this route table only exposes POST /validate-openapi plus the handle-based resource routes. As written, the new uniqueness-validation hook has no matching backend route in this handler.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/internal/handler/api.go` around lines 867 - 873, The route
table in apiGroup setup is missing the new REST API uniqueness validation
endpoint, so the validation hook has nothing to hit. Add a matching GET route
for the REST API validation path alongside the existing
GetAPI/ImportOpenAPI/ValidateOpenAPI registrations, and wire it to the
appropriate handler in this api.go handler setup so `validation.ts` can call
`GET /api/v0.9/rest-apis/validate` successfully.
Comment on lines
175
to
179
| // Extract UUID path parameter | ||
| gatewayId := c.Param("gatewayId") | ||
| gatewayId := c.Param("gatewayHandle") | ||
| if gatewayId == "" { | ||
| c.JSON(http.StatusBadRequest, utils.NewErrorResponse(400, "Bad Request", | ||
| "Gateway ID is required")) |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Update stale ID/UUID wording for handle routes.
These handlers now read gatewayHandle, but comments and 400 responses still mention ID/UUID/gatewayId. Align them with the new parameter name so client-facing errors match the REST contract.
Also applies to: 250-254, 291-319, 343-346, 378-382, 424-427, 467-470, 513-516, 552-558
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/internal/handler/gateway.go` around lines 175 - 179, Update
the handle-route validation text in gateway.go so the comments and 400 responses
consistently use gatewayHandle instead of stale ID/UUID/gatewayId wording. In
the gateway handler paths that read c.Param("gatewayHandle"), revise the nearby
comments and any utils.NewErrorResponse messages to match the new REST contract,
keeping the user-facing error text aligned across the affected handler blocks in
the gateway methods.
Comment on lines
8093
to
8100
| handle: | ||
| type: string | ||
| description: "URL-friendly unique identifier for the subscription plan. Auto-generated from name if omitted." | ||
| example: "gold" | ||
| name: | ||
| type: string | ||
| description: Name of the subscription plan | ||
| description: Human-readable name of the subscription plan | ||
| example: "Gold" |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Validate subscription plan handles against the advertised slug format.
These schemas describe handle as URL-friendly, but they do not constrain it, and the supplied service code only checks uniqueness/non-empty. Invalid handles can therefore be persisted and break the new handle-based path contract.
Also applies to: 8137-8149
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/resources/openapi.yaml` around lines 8093 - 8100, The
subscription plan `handle` is described as URL-friendly but is only validated
for presence/uniqueness, so update the `handle` schema in the OpenAPI
definitions and the subscription plan create/update validation logic to enforce
the advertised slug format. Use the existing subscription plan request/response
schemas around `handle` and `name` as the place to add the constraint, and
ensure the service code that currently checks only non-empty/unique values
rejects any handle that is not a slug-compatible identifier.
| ): Promise<{ data: GatewayConfigs }> { | ||
| const data = await getRequest<GatewayConfigs>( | ||
| `${GATEWAY_API_PATH}/${encodeURIComponent(gatewayId)}/configs?organizationId=${encodeURIComponent(organizationId)}`, | ||
| `${GATEWAY_API_PATH}/${encodeURIComponent(gatewayId)}/manifest?organizationId=${encodeURIComponent(organizationId)}`, |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Normalize the /manifest response before returning it.
This endpoint now returns the backend manifest wrapper (policies), but the existing consumer only understands raw config payloads or list/configs/data/items wrappers. As written, the configs drawer will parse the new response incorrectly and show no key manager entries. Unwrap policies here, or update the caller to handle the new envelope.
Suggested fix
+type GatewayManifestResponse = { policies: GatewayConfigs };
+
export async function getGatewayConfigs(
gatewayId: string,
organizationId: string
): Promise<{ data: GatewayConfigs }> {
- const data = await getRequest<GatewayConfigs>(
+ const response = await getRequest<GatewayManifestResponse | GatewayConfigs>(
`${GATEWAY_API_PATH}/${encodeURIComponent(gatewayId)}/manifest?organizationId=${encodeURIComponent(organizationId)}`,
undefined,
PLATFORM_API_BASE_URL
);
+ const data =
+ response &&
+ typeof response === "object" &&
+ !Array.isArray(response) &&
+ "policies" in response
+ ? response.policies
+ : response;
return { data };
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| `${GATEWAY_API_PATH}/${encodeURIComponent(gatewayId)}/manifest?organizationId=${encodeURIComponent(organizationId)}`, | |
| type GatewayManifestResponse = { policies: GatewayConfigs }; | |
| export async function getGatewayConfigs( | |
| gatewayId: string, | |
| organizationId: string | |
| ): Promise<{ data: GatewayConfigs }> { | |
| const response = await getRequest<GatewayManifestResponse | GatewayConfigs>( | |
| `${GATEWAY_API_PATH}/${encodeURIComponent(gatewayId)}/manifest?organizationId=${encodeURIComponent(organizationId)}`, | |
| undefined, | |
| PLATFORM_API_BASE_URL | |
| ); | |
| const data = | |
| response && | |
| typeof response === "object" && | |
| !Array.isArray(response) && | |
| "policies" in response | |
| ? response.policies | |
| : response; | |
| return { data }; | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@portals/ai-workspace/src/apis/gateway/gatewayApi.ts` at line 89, The gateway
manifest response is now wrapped in a policies envelope, but the existing
consumer in gatewayApi.ts still returns the raw backend shape, so the configs
drawer cannot read the key manager entries. Update the manifest
fetch/normalization path around the gateway API call to unwrap policies before
returning, or adjust the downstream parser to recognize this new envelope
alongside the existing raw/configs/data/items wrappers. Keep the fix localized
to the manifest handling logic and use the existing gatewayApi manifest request
as the entry point.
Comment on lines
170
to
+173
| const status = | ||
| typeof getGatewayStatus === "function" | ||
| ? getGatewayStatus(g.id) | ||
| : gatewayStatuses?.[g.id]; | ||
| ? getGatewayStatus(gwKey) | ||
| : gatewayStatuses?.[gwKey]; |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Look up statuses with the key they are stored under.
GatewayContext stores statuses by s.id, but this now queries with gwKey. When gwKey is a handle, gateways can render as inactive even when status data exists. Store statuses by handle too, or query by g.id with a handle fallback.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@portals/management-portal/src/pages/gateways/GatewayList.tsx` around lines
170 - 173, The gateway status lookup in GatewayList is using gwKey even though
GatewayContext stores statuses by s.id, so handle-based keys can miss existing
data and show inactive gateways. Update the status resolution in the GatewayList
logic to look up by the stored identifier used by the context (g.id/s.id), or
add a handle fallback so both id and handle-based keys are covered. Keep the
change aligned with the existing getGatewayStatus and gatewayStatuses access
pattern.
|
|
||
| try { | ||
| await rotateGatewayToken(gw.id); | ||
| await rotateGatewayToken(gw.handle ?? gw.name ?? gw.id); |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Keep the token cache key consistent with the lookup.
After this change, both rotation paths store tokens under handle ?? name ?? id, but createdToken is still read from gatewayTokens[createdGateway.id] on Line 439. If the handle differs from the UUID, the created-gateway summary never receives the token and the copy flow stays disabled. Derive one gatewayKey and use it for both rotation and lookup.
Also applies to: 506-506
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@portals/management-portal/src/pages/overview/StepHeader.tsx` at line 489, The
token cache key is inconsistent between rotation and lookup in StepHeader, so
created-token data can be missed when handle/name differs from id. Introduce a
single gatewayKey derived from handle ?? name ?? id and use it consistently in
rotateGatewayToken and when reading createdToken from gatewayTokens so the
created-gateway summary and copy flow stay in sync.
…ross various endpoints and models. Update related logic in deployment, gateway, and secret handlers to ensure consistency and clarity in API interactions.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 17
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
portals/ai-workspace/src/pages/appShell/appShellPages/proxies/LLMProxyDeploymentsCard.tsx (1)
108-116: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winFinish the gateway identity migration in this component.
Line 111 switches deployment matching to
gateway.handle, but this card still passes and storesgateway.idin the fetch, selection state, and gateway<MenuItem>values. With the updatedGatewaycontract, the selected gateway can no longer resolve reliably, so the invoke URL section can stop working. Migrate the remaininggateway.idreads here togateway.handle.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/ai-workspace/src/pages/appShell/appShellPages/proxies/LLMProxyDeploymentsCard.tsx` around lines 108 - 116, The gateway identity migration is only partially applied in LLMProxyDeploymentsCard: deployment lookup now uses gateway.handle, but the fetch flow, selected gateway state, and MenuItem values still rely on gateway.id. Update the remaining gateway identity reads in this component to use gateway.handle consistently so the selected gateway resolves correctly and the invoke URL section continues to work.portals/management-portal/src/pages/Gateway.tsx (2)
195-212: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winKeep the edit form handle stable.
The edit path seeds
namewithg.handle, but the follow-up load sets it fromfull.name; the display-name effect can also overwrite it. Preserve the handle while editing.Proposed fix
React.useEffect(() => { + if (editingId) return; setName(displayName ? slugify(displayName) : ""); -}, [displayName]); +}, [displayName, editingId]); ... - setName(full.name); + setName(full.handle);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/management-portal/src/pages/Gateway.tsx` around lines 195 - 212, The edit flow in Gateway.tsx is letting the form’s handle/name drift from the original gateway handle because the async fetch path and the display-name syncing logic both reset it. Update the edit initialization and the follow-up `fetchGatewayById` handling so the handle remains anchored to `g.handle` for the whole edit session, and adjust the display-name effect so it only updates the visible name field without overwriting the handle. Use the existing `editingIdRef`, `setName`, `setDisplayName`, and `fetchGatewayById` logic to keep the edit form stable.
228-253: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winValidate the generated handle before create.
handle: nameis now sent to the API, but the submit guard only checksdisplayName; display names that slugify to an empty or too-short handle will fail after submission.Proposed fix
const handleAddOrSave = async () => { - if (!displayName.trim() || isSubmitting) return; + const trimmedHandle = name.trim(); + if (!displayName.trim() || !/^[a-z0-9-]{3,64}$/.test(trimmedHandle) || isSubmitting) return; ... await createGateway({ - handle: name, + handle: trimmedHandle, name: displayName,🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/management-portal/src/pages/Gateway.tsx` around lines 228 - 253, The submit flow in handleAddOrSave only validates displayName, but createGateway now sends handle: name, so you need to validate the generated handle before calling the API. Update the Gateway.tsx logic in handleAddOrSave to derive/slugify the handle from the display name and reject empty or too-short results before createGateway is invoked, while keeping the existing edit path unchanged.platform-api/src/resources/openapi.yaml (1)
590-594: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winUpdate stale ID/UUID wording in handle-based operations.
These operations now use handle parameters, but several summaries/descriptions still refer to UUID,
apiId,providerId,proxyId, or gateway ID. Align the wording withapiHandle,providerHandle,proxyHandle,mcpProxyHandle, andgatewayHandle.Also applies to: 919-939, 971-989, 2831-2857, 2888-2911, 3468-3493, 3525-3548, 4067-4092, 4122-4145, 4461-4465
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/resources/openapi.yaml` around lines 590 - 594, Update the stale operation wording in the OpenAPI definitions so the summaries/descriptions no longer mention UUID, apiId, providerId, proxyId, or gateway ID for handle-based endpoints. In the affected GET/list operations and related schemas, align the text with the actual parameter names and terminology used in the spec: apiHandle, providerHandle, proxyHandle, mcpProxyHandle, and gatewayHandle. Keep the changes limited to the summary/description strings so the documented API terminology matches the current handle-based operations throughout the OpenAPI file.portals/management-portal/src/context/GatewayContext.tsx (1)
147-165: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winCompute
normalizedbefore using it
setGatewaysruns asynchronously, sonormalizedcan still be[]whensetGatewayTokensandreturn normalizedrun. Build the list first and reuse it for token pruning and the return value.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/management-portal/src/context/GatewayContext.tsx` around lines 147 - 165, Compute the normalized gateway list before updating state in GatewayContext so it is not read before assignment; build the merged Gateway[] from result and prev first, then pass that same value into setGateways and use it for setGatewayTokens token pruning and the returned state. Keep the fix localized around the normalization logic in GatewayContext and the mergeGateway/normalized flow.Source: Path instructions
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@platform-api/src/internal/handler/mcp_deployment.go`:
- Around line 395-396: The deployment list flow is using the external
`GatewayHandle` value where repository filtering expects the internal
`gateway.ID`, so `GetDeploymentsByHandle` ends up matching the wrong field.
Update the `GetDeploymentsByHandle` path in `mcp_deployment.go` to resolve
`params.GatewayHandle` to the gateway record first, then pass the internal ID
into the repository filter logic, following the same pattern used by the
undeploy/restore flow.
In `@platform-api/src/internal/handler/secret.go`:
- Around line 139-142: Update the required-parameter 400 responses in secret
handler logic to match the bound `handle` route parameter instead of saying
“Secret name is required.” In the `handle` validation branches within the secret
handler methods (the ones using `c.Param("handle")` and
`utils.NewErrorResponse`), change the message to “Secret handle is required”
consistently across all affected paths.
In `@platform-api/src/internal/handler/websub_api_deployment.go`:
- Around line 196-204: The deployment filter in websub_api_deployment.go is
using the external gateway handle string directly, but
GetWebSubAPIDeploymentsByHandle expects the internal gateway ID. Update the
handler logic around the gatewayHandle/status extraction to resolve
params.GatewayHandle to gateway.ID before calling
h.websubAPIDeploymentService.GetWebSubAPIDeploymentsByHandle, and pass the
resolved ID into the query so filtered deployment lists can match stored records
correctly.
In `@platform-api/src/internal/service/deployment.go`:
- Around line 775-783: The deployment response currently falls back to
d.GatewayID when s.gatewayRepo.GetByUUID returns nil, which populates
GatewayHandle with an ID instead of a handle. Update the logic in GetDeployment
and the shared response-building path to require a resolved gateway handle
before calling toAPIDeploymentResponse; if the lookup fails or gw is nil, return
an error instead of using the stored ID. Reference the GetDeployment method,
gatewayRepo.GetByUUID, and toAPIDeploymentResponse to apply the same behavior
consistently.
- Around line 430-433: The restore flow is passing gatewayHandle through
unchanged even though RestoreDeployment expects a gateway UUID and compares it
to targetDeployment.GatewayID. Update RestoreDeploymentByHandle to resolve the
handle to the corresponding gateway ID before calling the restore path, or move
that lookup into the service layer used by RestoreDeployment. Use the
RestoreDeploymentByHandle and RestoreDeployment symbols to locate the change and
ensure the response/lookup logic works with GatewayID rather than the raw
handle.
In `@platform-api/src/internal/service/llm_deployment.go`:
- Around line 493-501: Deployment response builders are falling back to gateway
IDs when handle lookup fails, which means the DTO field GatewayHandle can
contain the wrong identifier; update the affected getters and response mapping
paths (including the single-deployment getters and the code paths using
toAPIDeploymentResponse) so they only populate GatewayHandle with the resolved
gw.Handle/deployment gateway handle and do not substitute d.GatewayID or
deployment.GatewayID. Keep the same lookup pattern, but if the gateway cannot be
resolved, leave the handle empty or otherwise omit the fallback ID so UI
matching and filters stay handle-based.
In `@platform-api/src/internal/service/webbroker_api_deployment.go`:
- Around line 498-506: The gateway mapping in toAPIDeploymentResponse is
swallowing errors from s.gatewayRepo.GetByUUID and may return a raw GatewayID
where a handle is expected. Update the deployment response mapping logic
(including the other affected call site) to capture and return the lookup error
instead of ignoring it, and only fall back to the stored ID when the gateway is
intentionally missing for backward-compatibility. Use the existing symbols
GetByUUID, gwHandle, and toAPIDeploymentResponse to keep the fix consistent
across both paths.
- Around line 551-559: The list path is using the optional gateway handle
directly, but deployments are stored and queried by internal gateway ID, so
filtered results won’t match. Update the deployment listing flow in
webbroker_api_deployment.go so the incoming gatewayHandle is resolved to the
corresponding gateway record via the gateway repo before calling
GetDeploymentsWithState, using the existing gateway lookup logic around
s.gatewayRepo.GetByUUID and toAPIDeploymentResponse as a guide. Keep the filter
conversion isolated to the query path so stored rows are matched by gateway.ID
rather than the external handle.
In `@platform-api/src/internal/service/websub_api_deployment.go`:
- Line 355: The gateway lookup in the deployment path is comparing the handle
value against the internal deployment ID, which can cause incorrect matches. In
the websub deployment flow, resolve the passed gateway handle to the actual
gateway object first, then use its ID for both the lookup and any mismatch
validation in the relevant deployment handling logic. Update the comparison
points in the function that receives gatewayHandle so they consistently use
gateway.ID rather than the handle value.
- Around line 515-523: The deployments list query is using the incoming gateway
handle directly even though stored deployments are keyed by internal GatewayID,
so handle-filtered requests can miss matches. Update the list/filter flow in the
WebSub deployment service to resolve the optional handle to the gateway’s
internal ID before building the query, using the existing gateway lookup logic
around getByUUID/toAPIDeploymentResponse as the reference point. Ensure the
filter passed into the repository/query layer uses the resolved ID, while
response mapping can still expose the handle as needed.
- Around line 462-470: The gateway lookup in the deployment-to-response mapping
currently ignores the error from GetByUUID and falls back to GatewayID, which
can leak an internal ID into the handle field. Update the mapping logic around
toAPIDeploymentResponse in the deployment response path to handle the error
explicitly: return the error when the gateway lookup fails, and only use the
fallback value when that behavior is intentionally desired and documented. Use
the GetByUUID call and the deployment.GatewayID/gw.Handle handling as the key
points to fix both affected mapping sites.
In `@portals/ai-workspace/src/contexts/GatewayDeployContext.tsx`:
- Around line 128-144: The deployment refetch logic still uses gateway IDs for
proxy/MCP fetches even though the context contract now expects gateway handles,
so update refetchDeployments to pass gateway.handle into the per-gateway proxy
and MCP deployment loaders. Make the change in the refetch path that iterates
gateways and calls the deployment fetch helpers, keeping the rest of the
GatewayDeployContext contract unchanged so deployment history and polling state
populate correctly.
In
`@portals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ProviderMap/ProviderMapTab.tsx`:
- Around line 672-678: The deployment map is now keyed by gateway handle, but
the gateway card rendering in ProviderMapTab still uses gw.id for both the
lookup and row key. Update the remaining gateway lookup paths in this component
to use gw.handle consistently with deploymentsByGateway so each gateway card
resolves the correct deployment state.
In
`@portals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ServiceProviderOverview.tsx`:
- Around line 277-278: The gateway selection flow is inconsistent:
ServiceProviderOverview now resolves selectedGateway by gateway.handle, but
ServiceProviderDeploymentsCard still emits gateway.id from its dropdown, which
can make selectedGateway become null and clear the invoke URL. Update the
dropdown in ServiceProviderDeploymentsCard to use gateway.handle as the MenuItem
value, and keep the selectedGateway lookup in ServiceProviderOverview aligned
with that handle-based value end-to-end.
In `@portals/management-portal/src/context/GatewayContext.tsx`:
- Around line 182-188: In refreshGatewayStatuses, the full refresh path is
incorrectly merging fetched gateways into the existing gatewayStatuses map,
which leaves deleted gateways behind. Update the logic around setGatewayStatuses
so that the all-gateways refresh replaces the entire map from the fetched list,
while the single-gateway refresh path still merges into prev; use
refreshGatewayStatuses and the setGatewayStatuses updater in GatewayContext to
distinguish the two behaviors.
In `@portals/management-portal/src/hooks/gateways.ts`:
- Around line 178-187: The DELETE request in gateways.ts is still sending the
old gatewayId field even though DeleteGatewayPayload now uses gatewayHandle.
Update the delete request in the fetch call inside the gateway delete flow to
send gatewayHandle in the JSON body, or remove the body entirely if the route
already identifies the gateway via the path. Use the existing
payload.gatewayHandle reference so the request matches the renamed payload
shape.
In `@portals/management-portal/src/pages/apis/ApiDeploy/GatewayPickTable.tsx`:
- Around line 205-220: The table row identity has been switched to gw.handle in
GatewayPickTable, but other selection and filtering logic still uses g.id/gw.id,
which splits the state model. Update the remaining table logic to consistently
use handle in the relevant handlers and derived state (such as filtering,
selected counts, and bulk select-all toggles) so row selection stays in sync
with the render key and toggle behavior.
---
Outside diff comments:
In `@platform-api/src/resources/openapi.yaml`:
- Around line 590-594: Update the stale operation wording in the OpenAPI
definitions so the summaries/descriptions no longer mention UUID, apiId,
providerId, proxyId, or gateway ID for handle-based endpoints. In the affected
GET/list operations and related schemas, align the text with the actual
parameter names and terminology used in the spec: apiHandle, providerHandle,
proxyHandle, mcpProxyHandle, and gatewayHandle. Keep the changes limited to the
summary/description strings so the documented API terminology matches the
current handle-based operations throughout the OpenAPI file.
In
`@portals/ai-workspace/src/pages/appShell/appShellPages/proxies/LLMProxyDeploymentsCard.tsx`:
- Around line 108-116: The gateway identity migration is only partially applied
in LLMProxyDeploymentsCard: deployment lookup now uses gateway.handle, but the
fetch flow, selected gateway state, and MenuItem values still rely on
gateway.id. Update the remaining gateway identity reads in this component to use
gateway.handle consistently so the selected gateway resolves correctly and the
invoke URL section continues to work.
In `@portals/management-portal/src/context/GatewayContext.tsx`:
- Around line 147-165: Compute the normalized gateway list before updating state
in GatewayContext so it is not read before assignment; build the merged
Gateway[] from result and prev first, then pass that same value into setGateways
and use it for setGatewayTokens token pruning and the returned state. Keep the
fix localized around the normalization logic in GatewayContext and the
mergeGateway/normalized flow.
In `@portals/management-portal/src/pages/Gateway.tsx`:
- Around line 195-212: The edit flow in Gateway.tsx is letting the form’s
handle/name drift from the original gateway handle because the async fetch path
and the display-name syncing logic both reset it. Update the edit initialization
and the follow-up `fetchGatewayById` handling so the handle remains anchored to
`g.handle` for the whole edit session, and adjust the display-name effect so it
only updates the visible name field without overwriting the handle. Use the
existing `editingIdRef`, `setName`, `setDisplayName`, and `fetchGatewayById`
logic to keep the edit form stable.
- Around line 228-253: The submit flow in handleAddOrSave only validates
displayName, but createGateway now sends handle: name, so you need to validate
the generated handle before calling the API. Update the Gateway.tsx logic in
handleAddOrSave to derive/slugify the handle from the display name and reject
empty or too-short results before createGateway is invoked, while keeping the
existing edit path unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1edd427e-6bb8-477b-9cb7-860f5424a5fa
📒 Files selected for processing (54)
platform-api/src/api/generated.goplatform-api/src/internal/dto/secret.goplatform-api/src/internal/handler/api.goplatform-api/src/internal/handler/api_deployment.goplatform-api/src/internal/handler/gateway.goplatform-api/src/internal/handler/gateway_internal.goplatform-api/src/internal/handler/llm_deployment.goplatform-api/src/internal/handler/mcp_deployment.goplatform-api/src/internal/handler/secret.goplatform-api/src/internal/handler/subscription_plan_handler.goplatform-api/src/internal/handler/webbroker_api_deployment.goplatform-api/src/internal/handler/websub_api_deployment.goplatform-api/src/internal/service/api.goplatform-api/src/internal/service/deployment.goplatform-api/src/internal/service/gateway.goplatform-api/src/internal/service/llm_deployment.goplatform-api/src/internal/service/mcp_deployment.goplatform-api/src/internal/service/secret_service.goplatform-api/src/internal/service/webbroker_api_deployment.goplatform-api/src/internal/service/websub_api_deployment.goplatform-api/src/resources/openapi.yamlportals/ai-workspace/src/Components/GatewayDeploy/GatewayDeployCard.tsxportals/ai-workspace/src/Components/GatewayDeploy/GatewayDeployCardContent.tsxportals/ai-workspace/src/Components/GatewayDeploy/GatewayDeployEnvCard.tsxportals/ai-workspace/src/Components/GatewayDeploy/GatewayDeploymentHistory.tsxportals/ai-workspace/src/Components/GatewayDeploy/GatewayDeploymentSelector.tsxportals/ai-workspace/src/apis/MCP/mcpServerDeployApis.tsportals/ai-workspace/src/apis/gateway/gatewayApi.tsportals/ai-workspace/src/apis/gateway/types.tsportals/ai-workspace/src/apis/gatewayApis.tsportals/ai-workspace/src/apis/gatewayTypes.tsportals/ai-workspace/src/apis/llmProviderApis.tsportals/ai-workspace/src/apis/llmProxiesApis.tsportals/ai-workspace/src/contexts/GatewayDeployContext.tsxportals/ai-workspace/src/contexts/MCP/MCPServerDeployContext.tsxportals/ai-workspace/src/pages/appShell/appShellPages/externalServers/ExternalServersOverview.tsxportals/ai-workspace/src/pages/appShell/appShellPages/proxies/LLMProxyDeploymentsCard.tsxportals/ai-workspace/src/pages/appShell/appShellPages/proxies/LLMProxyOverviewTab.tsxportals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ProviderMap/ProviderMapTab.tsxportals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ServiceProviderDeploy.tsxportals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ServiceProviderDeploymentsCard.tsxportals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ServiceProviderOverview.tsxportals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ServiceProviderOverviewTab.tsxportals/ai-workspace/src/utils/types.tsportals/management-portal/src/context/DeploymentContext.tsxportals/management-portal/src/context/GatewayContext.tsxportals/management-portal/src/hooks/apis.tsportals/management-portal/src/hooks/deployments.tsportals/management-portal/src/hooks/gateways.tsportals/management-portal/src/pages/Gateway.tsxportals/management-portal/src/pages/apis/ApiDeploy/GatewayDeployCard.tsxportals/management-portal/src/pages/apis/ApiDeploy/GatewayPickTable.tsxportals/management-portal/src/pages/apis/ApiDevelop.tsxportals/management-portal/src/pages/apis/ApiPublish/ApiPublishForm.tsx
💤 Files with no reviewable changes (3)
- platform-api/src/internal/handler/gateway_internal.go
- platform-api/src/internal/service/secret_service.go
- platform-api/src/internal/service/gateway.go
✅ Files skipped from review due to trivial changes (1)
- platform-api/src/api/generated.go
🚧 Files skipped from review as they are similar to previous changes (5)
- portals/ai-workspace/src/apis/MCP/mcpServerDeployApis.ts
- portals/ai-workspace/src/apis/llmProxiesApis.ts
- platform-api/src/internal/handler/api.go
- platform-api/src/internal/handler/api_deployment.go
- platform-api/src/internal/handler/subscription_plan_handler.go
Comment on lines
139
to
142
| handle := c.Param("handle") | ||
| if handle == "" { | ||
| c.JSON(http.StatusBadRequest, utils.NewErrorResponse(400, "Bad Request", "Secret name is required")) | ||
| return |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Align required-parameter text with handle.
These routes now bind :handle, but the 400 responses still say “Secret name is required.” Use “Secret handle is required” to match the API contract.
Proposed fix
- c.JSON(http.StatusBadRequest, utils.NewErrorResponse(400, "Bad Request", "Secret name is required"))
+ c.JSON(http.StatusBadRequest, utils.NewErrorResponse(400, "Bad Request", "Secret handle is required"))Also applies to: 166-169, 201-204
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/internal/handler/secret.go` around lines 139 - 142, Update
the required-parameter 400 responses in secret handler logic to match the bound
`handle` route parameter instead of saying “Secret name is required.” In the
`handle` validation branches within the secret handler methods (the ones using
`c.Param("handle")` and `utils.NewErrorResponse`), change the message to “Secret
handle is required” consistently across all affected paths.
Comment on lines
+196
to
+204
| var gatewayHandle, status string | ||
| if params.GatewayHandle != nil { | ||
| gatewayHandle = string(*params.GatewayHandle) | ||
| } | ||
| if params.Status != nil { | ||
| status = string(*params.Status) | ||
| } | ||
|
|
||
| deployments, err := h.websubAPIDeploymentService.GetWebSubAPIDeploymentsByHandle(apiId, gatewayId, status, orgId) | ||
| deployments, err := h.websubAPIDeploymentService.GetWebSubAPIDeploymentsByHandle(apiId, gatewayHandle, status, orgId) |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Resolve gatewayHandle before applying the deployment filter.
GetWebSubAPIDeploymentsByHandle receives a handle, but deployments are stored against the internal gateway ID. Convert the handle to gateway.ID before querying, otherwise filtered list calls can return no matches.
As per path instructions, this focuses on correctness and best practices.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/internal/handler/websub_api_deployment.go` around lines 196
- 204, The deployment filter in websub_api_deployment.go is using the external
gateway handle string directly, but GetWebSubAPIDeploymentsByHandle expects the
internal gateway ID. Update the handler logic around the gatewayHandle/status
extraction to resolve params.GatewayHandle to gateway.ID before calling
h.websubAPIDeploymentService.GetWebSubAPIDeploymentsByHandle, and pass the
resolved ID into the query so filtered deployment lists can match stored records
correctly.
Source: Path instructions
Comment on lines
430
to
+433
| return toAPIDeploymentResponse( | ||
| targetDeployment.DeploymentID, | ||
| targetDeployment.Name, | ||
| targetDeployment.GatewayID, | ||
| gateway.Handle, |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify restore handlers either convert gatewayHandle to gateway ID before calling RestoreDeployment,
# or that RestoreDeployment is migrated to resolve handles internally.
rg -n -C3 'RestoreDeployment\(' platform-api/src/internal
rg -n -C3 'gatewayHandle|gatewayID|gatewayId' platform-api/src/internal/handler platform-api/src/internal/serviceRepository: wso2/api-platform
Length of output: 50374
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- deployment.go restore-related symbols ---'
ast-grep outline platform-api/src/internal/service/deployment.go --view expanded | sed -n '1,220p'
echo
echo '--- service restore implementations ---'
rg -n -C 8 'func .*Restore(LLMProxy)?Deployment|GatewayID|gatewayHandle|gatewayID' platform-api/src/internal/service/deployment.go
echo
echo '--- handler restore call sites ---'
rg -n -C 4 'Restore(LLMProxy)?Deployment\(|gatewayHandle|gatewayID' platform-api/src/internal/handler | sed -n '1,220p'Repository: wso2/api-platform
Length of output: 40008
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- handler files mentioning API restore ---'
rg -n -C 4 'RestoreDeploymentByHandle|RestoreDeployment\(' platform-api/src/internal/handler | sed -n '1,240p'
echo
echo '--- deployment handler file names ---'
fd -a '.*deployment.*\.go$' platform-api/src/internal/handler
echo
echo '--- gateway lookup helpers in handler ---'
rg -n -C 3 'GetByHandleAndOrgID|GetByUUID|gatewayHandle' platform-api/src/internal/handler/*deployment*.go | sed -n '1,260p'Repository: wso2/api-platform
Length of output: 26932
Restore still needs a gateway UUID here. RestoreDeploymentByHandle forwards the query-string gatewayHandle unchanged, and RestoreDeployment compares it against targetDeployment.GatewayID. Resolve the handle before calling restore, or move the lookup into the service.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/internal/service/deployment.go` around lines 430 - 433, The
restore flow is passing gatewayHandle through unchanged even though
RestoreDeployment expects a gateway UUID and compares it to
targetDeployment.GatewayID. Update RestoreDeploymentByHandle to resolve the
handle to the corresponding gateway ID before calling the restore path, or move
that lookup into the service layer used by RestoreDeployment. Use the
RestoreDeploymentByHandle and RestoreDeployment symbols to locate the change and
ensure the response/lookup logic works with GatewayID rather than the raw
handle.
Comment on lines
+775
to
+783
| gw, _ := s.gatewayRepo.GetByUUID(d.GatewayID) | ||
| gwHandle := d.GatewayID | ||
| if gw != nil { | ||
| gwHandle = gw.Handle | ||
| } | ||
| mapped, err := toAPIDeploymentResponse( | ||
| d.DeploymentID, | ||
| d.Name, | ||
| d.GatewayID, | ||
| gwHandle, |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Do not fall back to gateway ID for GatewayHandle.
If the gateway lookup fails or returns nil, GatewayHandle is populated with the stored gateway ID. That violates the response contract and breaks handle-based clients. Return an error or resolve the handle before building the response.
Proposed fix
- gw, _ := s.gatewayRepo.GetByUUID(d.GatewayID)
- gwHandle := d.GatewayID
- if gw != nil {
- gwHandle = gw.Handle
- }
+ gw, err := s.gatewayRepo.GetByUUID(d.GatewayID)
+ if err != nil {
+ return nil, fmt.Errorf("failed to get gateway: %w", err)
+ }
+ if gw == nil {
+ return nil, constants.ErrGatewayNotFound
+ }
mapped, err := toAPIDeploymentResponse(
d.DeploymentID,
d.Name,
- gwHandle,
+ gw.Handle,Apply the same handling in GetDeployment.
Also applies to: 823-831
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@platform-api/src/internal/service/deployment.go` around lines 775 - 783, The
deployment response currently falls back to d.GatewayID when
s.gatewayRepo.GetByUUID returns nil, which populates GatewayHandle with an ID
instead of a handle. Update the logic in GetDeployment and the shared
response-building path to require a resolved gateway handle before calling
toAPIDeploymentResponse; if the lookup fails or gw is nil, return an error
instead of using the stored ID. Reference the GetDeployment method,
gatewayRepo.GetByUUID, and toAPIDeploymentResponse to apply the same behavior
consistently.
Comment on lines
672
to
+678
| const deploymentsByGateway = deployments.reduce< | ||
| Record<string, DeploymentResponse> | ||
| >((acc, dep) => { | ||
| if (dep.gatewayId && dep.status === 'DEPLOYED') { | ||
| acc[dep.gatewayId] = dep; | ||
| } else if (dep.gatewayId && !acc[dep.gatewayId]) { | ||
| acc[dep.gatewayId] = dep; | ||
| if (dep.gatewayHandle && dep.status === 'DEPLOYED') { | ||
| acc[dep.gatewayHandle] = dep; | ||
| } else if (dep.gatewayHandle && !acc[dep.gatewayHandle]) { | ||
| acc[dep.gatewayHandle] = dep; |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Keep the deployment map and gateway lookups on the same key.
This reducer now stores entries by dep.gatewayHandle, but the gateway cards below still read deploymentsByGateway[gw.id] and key rows with gw.id. As written, those cards will miss their deployment entry and show the wrong deployment state. Switch the remaining lookups in this component to gw.handle.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@portals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ProviderMap/ProviderMapTab.tsx`
around lines 672 - 678, The deployment map is now keyed by gateway handle, but
the gateway card rendering in ProviderMapTab still uses gw.id for both the
lookup and row key. Update the remaining gateway lookup paths in this component
to use gw.handle consistently with deploymentsByGateway so each gateway card
resolves the correct deployment state.
Comment on lines
+277
to
278
| () => gateways.find((gateway) => gateway.handle === selectedGatewayId) ?? null, | ||
| [gateways, selectedGatewayId] |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Keep the gateway selector value handle-based end-to-end.
This state now stores gateway.handle, but the deployment card still emits gateway.id from its dropdown. Selecting a gateway can make selectedGateway resolve to null and clear the generated invoke URL.
Proposed fix
- const [selectedGatewayId, setSelectedGatewayId] = useState('');
+ const [selectedGatewayHandle, setSelectedGatewayHandle] = useState('');
const selectedGateway = useMemo(
- () => gateways.find((gateway) => gateway.handle === selectedGatewayId) ?? null,
- [gateways, selectedGatewayId]
+ () =>
+ gateways.find((gateway) => gateway.handle === selectedGatewayHandle) ??
+ null,
+ [gateways, selectedGatewayHandle]
);
- setSelectedGatewayId((currentSelectedId) => {
+ setSelectedGatewayHandle((currentSelectedHandle) => {
if (
- currentSelectedId &&
- deployedGateways.some((gateway) => gateway.handle === currentSelectedId)
+ currentSelectedHandle &&
+ deployedGateways.some(
+ (gateway) => gateway.handle === currentSelectedHandle
+ )
) {
- return currentSelectedId;
+ return currentSelectedHandle;
}
return deployedGateways[0]?.handle || '';
});Also update ServiceProviderDeploymentsCard to pass gateway.handle as the <MenuItem value>.
Also applies to: 638-645
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@portals/ai-workspace/src/pages/appShell/appShellPages/serviceProvider/ServiceProviderOverview.tsx`
around lines 277 - 278, The gateway selection flow is inconsistent:
ServiceProviderOverview now resolves selectedGateway by gateway.handle, but
ServiceProviderDeploymentsCard still emits gateway.id from its dropdown, which
can make selectedGateway become null and clear the invoke URL. Update the
dropdown in ServiceProviderDeploymentsCard to use gateway.handle as the MenuItem
value, and keep the selectedGateway lookup in ServiceProviderOverview aligned
with that handle-based value end-to-end.
Comment on lines
182
to
+188
| setGatewayStatuses((prev) => { | ||
| const next = { ...prev }; | ||
| for (const s of list) next[s.id] = s; | ||
| for (const s of list) next[s.handle] = s; | ||
| return next; | ||
| }); | ||
| return list.reduce<Record<string, GatewayStatus>>((acc, s) => { | ||
| acc[s.id] = s; | ||
| acc[s.handle] = s; |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Replace statuses on full refresh.
When refreshGatewayStatuses() fetches all gateways, merging into prev keeps deleted gateways in gatewayStatuses. Replace the map for full refreshes and only merge for single-gateway refreshes.
As per path instructions, this focuses on correctness and best practices.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@portals/management-portal/src/context/GatewayContext.tsx` around lines 182 -
188, In refreshGatewayStatuses, the full refresh path is incorrectly merging
fetched gateways into the existing gatewayStatuses map, which leaves deleted
gateways behind. Update the logic around setGatewayStatuses so that the
all-gateways refresh replaces the entire map from the fetched list, while the
single-gateway refresh path still merges into prev; use refreshGatewayStatuses
and the setGatewayStatuses updater in GatewayContext to distinguish the two
behaviors.
Source: Path instructions
Comment on lines
178
to
187
| const response = await fetch( | ||
| `${baseUrl}/api/v0.9/gateways/${payload.gatewayId}`, | ||
| `${baseUrl}/api/v0.9/gateways/${payload.gatewayHandle}`, | ||
| { | ||
| method: "DELETE", | ||
| headers: { | ||
| Authorization: `Bearer ${token}`, | ||
| "Content-Type": "application/json", | ||
| }, | ||
| body: JSON.stringify({ gatewayId: payload.gatewayId }), | ||
| body: JSON.stringify({ gatewayId: payload.gatewayHandle }), | ||
| } |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Send the renamed delete payload field.
DeleteGatewayPayload now exposes gatewayHandle, but the request body still sends gatewayId. Use gatewayHandle in the body, or omit the body if the path parameter is sufficient.
As per path instructions, this focuses on correctness and best practices.
Proposed fix
- body: JSON.stringify({ gatewayId: payload.gatewayHandle }),
+ body: JSON.stringify({ gatewayHandle: payload.gatewayHandle }),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const response = await fetch( | |
| `${baseUrl}/api/v0.9/gateways/${payload.gatewayId}`, | |
| `${baseUrl}/api/v0.9/gateways/${payload.gatewayHandle}`, | |
| { | |
| method: "DELETE", | |
| headers: { | |
| Authorization: `Bearer ${token}`, | |
| "Content-Type": "application/json", | |
| }, | |
| body: JSON.stringify({ gatewayId: payload.gatewayId }), | |
| body: JSON.stringify({ gatewayId: payload.gatewayHandle }), | |
| } | |
| const response = await fetch( | |
| `${baseUrl}/api/v0.9/gateways/${payload.gatewayHandle}`, | |
| { | |
| method: "DELETE", | |
| headers: { | |
| Authorization: `Bearer ${token}`, | |
| "Content-Type": "application/json", | |
| }, | |
| body: JSON.stringify({ gatewayHandle: payload.gatewayHandle }), | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@portals/management-portal/src/hooks/gateways.ts` around lines 178 - 187, The
DELETE request in gateways.ts is still sending the old gatewayId field even
though DeleteGatewayPayload now uses gatewayHandle. Update the delete request in
the fetch call inside the gateway delete flow to send gatewayHandle in the JSON
body, or remove the body entirely if the route already identifies the gateway
via the path. Use the existing payload.gatewayHandle reference so the request
matches the renamed payload shape.
Source: Path instructions
Comment on lines
+205
to
+220
| const isChecked = selectedIds.has(gw.handle); | ||
| const title = gw.name || "Gateway"; | ||
| const initial = (title || "?").trim().charAt(0).toUpperCase(); | ||
| const last = gw.updatedAt || gw.createdAt || null; | ||
| const vhost = gw.vhost || "—"; | ||
| const apisCount = 2; // hard-coded as requested | ||
|
|
||
| return ( | ||
| <React.Fragment key={gw.id}> | ||
| <React.Fragment key={gw.handle}> | ||
| <TableRow> | ||
| <TableCell | ||
| colSpan={6} | ||
| sx={{ p: 0, border: 0, background: "transparent" }} | ||
| > | ||
| <Box | ||
| onClick={() => onToggleRow(gw.id)} | ||
| onClick={() => onToggleRow(gw.handle)} |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Use handle consistently across the table state.
This hunk moves row identity to gw.handle, but the rest of the table still filters, counts, and bulk-toggles rows with g.id/gw.id. That splits the selection model in two, so row selection, select-all, and hidden deployed rows can drift out of sync. Update the remaining table logic to use handle as well.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@portals/management-portal/src/pages/apis/ApiDeploy/GatewayPickTable.tsx`
around lines 205 - 220, The table row identity has been switched to gw.handle in
GatewayPickTable, but other selection and filtering logic still uses g.id/gw.id,
which splits the state model. Update the remaining table logic to consistently
use handle in the relevant handlers and derived state (such as filtering,
selected counts, and bulk select-all toggles) so row selection stays in sync
with the render key and toggle behavior.
…name' and 'handle' to 'id' across various components. Update descriptions for clarity and consistency in API documentation.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
platform-api/src/internal/handler/mcp.go (1)
248-265: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
Warnfor these 4xx mappings.These branches return expected client errors, but they are still logged at
Error, which makes routine validation failures look like server faults. Based on learnings, expected 4xx responses in internal handlers should useslog.Warn, notslog.Error.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/mcp.go` around lines 248 - 265, The MCP error-mapping branches in the handler should not log expected 4xx client failures as errors. Update the relevant cases in the MCP request handling logic to use h.slogger.Warn instead of h.slogger.Error for the ErrInvalidInput, ErrMCPProxyNotFound, ErrMCPProxyExists, ErrProjectNotFound, ErrMCPProxyLimitReached, and ErrSecretRefMissing paths, while keeping the same response behavior and reason payloads.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@platform-api/src/internal/handler/api_deployment.go`:
- Around line 148-156: The deployment handlers are still reading the old query
parameter name instead of the new gatewayHandle field, so requests using the
updated API are mishandled. Update the query parsing and related validation in
the deployment handler paths that use gatewayId, including the undeploy/restore
and listing flows, so they consistently read gatewayHandle and propagate it
through the existing DTO and handler logic. Make sure the checks, error
messages, and any request-to-service mapping in the affected handler methods use
the same gatewayHandle identifier everywhere.
In `@platform-api/src/internal/handler/llm_apikey.go`:
- Around line 58-61: The `providerHandle` validation in `llm_apikey.go` has a
mismatched 400 message: the handlers currently read `providerHandle` from the
path but return “LLM provider ID is required,” which is inconsistent with the
route contract. Update the bad-request responses in the affected handler checks
(including the ones in the `providerHandle` validation blocks) to use wording
that matches `providerHandle` consistently, and keep the same phrasing across
all three locations.
In `@platform-api/src/internal/handler/mcp_deployment.go`:
- Around line 156-164: The query parameter name is inconsistent across the mcp
deployment handlers: `gatewayId` is still being read in the undeploy/restore and
list paths even though validation and the DTO now use `gatewayHandle`. Update
the relevant `r.URL.Query().Get(...)` calls in the affected handler functions to
read `gatewayHandle` consistently, and keep the existing required-field checks
and filter logic aligned with that same symbol so requests using the new name
work everywhere.
In `@platform-api/src/internal/handler/mcp.go`:
- Around line 229-231: The MCP unauthorized handling in the relevant error
branch of mcp.go is returning a 401 status with a 400/Bad Request payload, which
creates conflicting response metadata. Update the `errors.Is(err,
constants.ErrMCPServerUnauthorized)` path in the MCP handler to build a
401-shaped error body that matches `http.StatusUnauthorized`, and keep the
response message aligned with unauthorized/credential failure semantics. Use the
existing `httputil.WriteJSON` and `utils.NewErrorResponse` call sites in
`mcp.go` to ensure the status code and payload agree.
---
Nitpick comments:
In `@platform-api/src/internal/handler/mcp.go`:
- Around line 248-265: The MCP error-mapping branches in the handler should not
log expected 4xx client failures as errors. Update the relevant cases in the MCP
request handling logic to use h.slogger.Warn instead of h.slogger.Error for the
ErrInvalidInput, ErrMCPProxyNotFound, ErrMCPProxyExists, ErrProjectNotFound,
ErrMCPProxyLimitReached, and ErrSecretRefMissing paths, while keeping the same
response behavior and reason payloads.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f81dadaa-3015-47e8-be41-8b4e60c74d21
📒 Files selected for processing (23)
platform-api/src/internal/handler/api.goplatform-api/src/internal/handler/api_deployment.goplatform-api/src/internal/handler/api_key.goplatform-api/src/internal/handler/application.goplatform-api/src/internal/handler/gateway.goplatform-api/src/internal/handler/gateway_internal.goplatform-api/src/internal/handler/llm.goplatform-api/src/internal/handler/llm_apikey.goplatform-api/src/internal/handler/llm_deployment.goplatform-api/src/internal/handler/llm_proxy_apikey.goplatform-api/src/internal/handler/mcp.goplatform-api/src/internal/handler/mcp_deployment.goplatform-api/src/internal/handler/secret.goplatform-api/src/internal/handler/subscription_plan_handler.goplatform-api/src/internal/handler/webbroker_api.goplatform-api/src/internal/handler/webbroker_api_deployment.goplatform-api/src/internal/handler/webbroker_apikey.goplatform-api/src/internal/handler/websub_api.goplatform-api/src/internal/handler/websub_api_deployment.goplatform-api/src/internal/handler/websub_api_hmac_secret.goplatform-api/src/internal/handler/websub_apikey.goplatform-api/src/internal/service/api.goplatform-api/src/resources/openapi.yaml
💤 Files with no reviewable changes (9)
- platform-api/src/internal/handler/websub_apikey.go
- platform-api/src/internal/handler/webbroker_apikey.go
- platform-api/src/internal/handler/websub_api.go
- platform-api/src/internal/handler/websub_api_hmac_secret.go
- platform-api/src/internal/handler/websub_api_deployment.go
- platform-api/src/internal/service/api.go
- platform-api/src/internal/handler/webbroker_api_deployment.go
- platform-api/src/internal/handler/subscription_plan_handler.go
- platform-api/src/internal/handler/webbroker_api.go
🚧 Files skipped from review as they are similar to previous changes (6)
- platform-api/src/internal/handler/secret.go
- platform-api/src/internal/handler/llm_proxy_apikey.go
- platform-api/src/internal/handler/api_key.go
- platform-api/src/internal/handler/gateway_internal.go
- platform-api/src/internal/handler/llm.go
- platform-api/src/internal/handler/application.go
Contributor
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 4
🧹 Nitpick comments (1)
platform-api/src/internal/handler/mcp.go (1)
248-265: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse
Warnfor these 4xx mappings.These branches return expected client errors, but they are still logged at
Error, which makes routine validation failures look like server faults. Based on learnings, expected 4xx responses in internal handlers should useslog.Warn, notslog.Error.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/mcp.go` around lines 248 - 265, The MCP error-mapping branches in the handler should not log expected 4xx client failures as errors. Update the relevant cases in the MCP request handling logic to use h.slogger.Warn instead of h.slogger.Error for the ErrInvalidInput, ErrMCPProxyNotFound, ErrMCPProxyExists, ErrProjectNotFound, ErrMCPProxyLimitReached, and ErrSecretRefMissing paths, while keeping the same response behavior and reason payloads.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@platform-api/src/internal/handler/api_deployment.go`:
- Around line 148-156: The deployment handlers are still reading the old query
parameter name instead of the new gatewayHandle field, so requests using the
updated API are mishandled. Update the query parsing and related validation in
the deployment handler paths that use gatewayId, including the undeploy/restore
and listing flows, so they consistently read gatewayHandle and propagate it
through the existing DTO and handler logic. Make sure the checks, error
messages, and any request-to-service mapping in the affected handler methods use
the same gatewayHandle identifier everywhere.
In `@platform-api/src/internal/handler/llm_apikey.go`:
- Around line 58-61: The `providerHandle` validation in `llm_apikey.go` has a
mismatched 400 message: the handlers currently read `providerHandle` from the
path but return “LLM provider ID is required,” which is inconsistent with the
route contract. Update the bad-request responses in the affected handler checks
(including the ones in the `providerHandle` validation blocks) to use wording
that matches `providerHandle` consistently, and keep the same phrasing across
all three locations.
In `@platform-api/src/internal/handler/mcp_deployment.go`:
- Around line 156-164: The query parameter name is inconsistent across the mcp
deployment handlers: `gatewayId` is still being read in the undeploy/restore and
list paths even though validation and the DTO now use `gatewayHandle`. Update
the relevant `r.URL.Query().Get(...)` calls in the affected handler functions to
read `gatewayHandle` consistently, and keep the existing required-field checks
and filter logic aligned with that same symbol so requests using the new name
work everywhere.
In `@platform-api/src/internal/handler/mcp.go`:
- Around line 229-231: The MCP unauthorized handling in the relevant error
branch of mcp.go is returning a 401 status with a 400/Bad Request payload, which
creates conflicting response metadata. Update the `errors.Is(err,
constants.ErrMCPServerUnauthorized)` path in the MCP handler to build a
401-shaped error body that matches `http.StatusUnauthorized`, and keep the
response message aligned with unauthorized/credential failure semantics. Use the
existing `httputil.WriteJSON` and `utils.NewErrorResponse` call sites in
`mcp.go` to ensure the status code and payload agree.
---
Nitpick comments:
In `@platform-api/src/internal/handler/mcp.go`:
- Around line 248-265: The MCP error-mapping branches in the handler should not
log expected 4xx client failures as errors. Update the relevant cases in the MCP
request handling logic to use h.slogger.Warn instead of h.slogger.Error for the
ErrInvalidInput, ErrMCPProxyNotFound, ErrMCPProxyExists, ErrProjectNotFound,
ErrMCPProxyLimitReached, and ErrSecretRefMissing paths, while keeping the same
response behavior and reason payloads.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f81dadaa-3015-47e8-be41-8b4e60c74d21
📒 Files selected for processing (23)
platform-api/src/internal/handler/api.goplatform-api/src/internal/handler/api_deployment.goplatform-api/src/internal/handler/api_key.goplatform-api/src/internal/handler/application.goplatform-api/src/internal/handler/gateway.goplatform-api/src/internal/handler/gateway_internal.goplatform-api/src/internal/handler/llm.goplatform-api/src/internal/handler/llm_apikey.goplatform-api/src/internal/handler/llm_deployment.goplatform-api/src/internal/handler/llm_proxy_apikey.goplatform-api/src/internal/handler/mcp.goplatform-api/src/internal/handler/mcp_deployment.goplatform-api/src/internal/handler/secret.goplatform-api/src/internal/handler/subscription_plan_handler.goplatform-api/src/internal/handler/webbroker_api.goplatform-api/src/internal/handler/webbroker_api_deployment.goplatform-api/src/internal/handler/webbroker_apikey.goplatform-api/src/internal/handler/websub_api.goplatform-api/src/internal/handler/websub_api_deployment.goplatform-api/src/internal/handler/websub_api_hmac_secret.goplatform-api/src/internal/handler/websub_apikey.goplatform-api/src/internal/service/api.goplatform-api/src/resources/openapi.yaml
💤 Files with no reviewable changes (9)
- platform-api/src/internal/handler/websub_apikey.go
- platform-api/src/internal/handler/webbroker_apikey.go
- platform-api/src/internal/handler/websub_api.go
- platform-api/src/internal/handler/websub_api_hmac_secret.go
- platform-api/src/internal/handler/websub_api_deployment.go
- platform-api/src/internal/service/api.go
- platform-api/src/internal/handler/webbroker_api_deployment.go
- platform-api/src/internal/handler/subscription_plan_handler.go
- platform-api/src/internal/handler/webbroker_api.go
🚧 Files skipped from review as they are similar to previous changes (6)
- platform-api/src/internal/handler/secret.go
- platform-api/src/internal/handler/llm_proxy_apikey.go
- platform-api/src/internal/handler/api_key.go
- platform-api/src/internal/handler/gateway_internal.go
- platform-api/src/internal/handler/llm.go
- platform-api/src/internal/handler/application.go
🛑 Comments failed to post (4)
platform-api/src/internal/handler/api_deployment.go (1)
148-156: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
The deployment endpoints still read
gatewayId.Lines 148, 221, and 399 pull
gatewayIdfrom the query string, but the surrounding validation and DTO field now usegatewayHandle. Requests using the new name will be rejected in undeploy/restore and ignored in deployment listing.Proposed fix
- gatewayId := r.URL.Query().Get("gatewayId") + gatewayHandle := r.URL.Query().Get("gatewayHandle") ... - if gatewayId == "" { + if gatewayHandle == "" { httputil.WriteJSON(w, http.StatusBadRequest, utils.NewErrorResponse(400, "Bad Request", "gatewayHandle is required")) return } ... - deployment, err := h.deploymentService.UndeployDeploymentByHandle(apiId, deploymentId, gatewayId, orgId, actor) + deployment, err := h.deploymentService.UndeployDeploymentByHandle(apiId, deploymentId, gatewayHandle, orgId, actor)Also applies to: 221-229, 399-401
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/api_deployment.go` around lines 148 - 156, The deployment handlers are still reading the old query parameter name instead of the new gatewayHandle field, so requests using the updated API are mishandled. Update the query parsing and related validation in the deployment handler paths that use gatewayId, including the undeploy/restore and listing flows, so they consistently read gatewayHandle and propagate it through the existing DTO and handler logic. Make sure the checks, error messages, and any request-to-service mapping in the affected handler methods use the same gatewayHandle identifier everywhere.platform-api/src/internal/handler/llm_apikey.go (1)
58-61: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Match the 400 text to
providerHandle.Lines 58, 92, and 144 validate the
providerHandlepath value, but the response body still saysLLM provider ID is required. That leaves client errors out of sync with the route contract.Also applies to: 92-95, 144-147
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/llm_apikey.go` around lines 58 - 61, The `providerHandle` validation in `llm_apikey.go` has a mismatched 400 message: the handlers currently read `providerHandle` from the path but return “LLM provider ID is required,” which is inconsistent with the route contract. Update the bad-request responses in the affected handler checks (including the ones in the `providerHandle` validation blocks) to use wording that matches `providerHandle` consistently, and keep the same phrasing across all three locations.platform-api/src/internal/handler/mcp_deployment.go (1)
156-164: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Read
gatewayHandlefrom the query string consistently.Lines 156, 222, and 387 still call
Query().Get("gatewayId"), even though the surrounding validation and DTO field now usegatewayHandle. Requests using the new name will fail undeploy/restore validation, and filtered list requests will ignore the gateway filter.Proposed fix
- gatewayId := r.URL.Query().Get("gatewayId") + gatewayHandle := r.URL.Query().Get("gatewayHandle") ... - if gatewayId == "" { + if gatewayHandle == "" { httputil.WriteJSON(w, http.StatusBadRequest, utils.NewErrorResponse(400, "Bad Request", "gatewayHandle is required")) return } ... - deployment, err := h.deploymentService.UndeployDeploymentByHandle(proxyId, deploymentId, gatewayId, orgId) + deployment, err := h.deploymentService.UndeployDeploymentByHandle(proxyId, deploymentId, gatewayHandle, orgId)Also applies to: 222-231, 387-390
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/mcp_deployment.go` around lines 156 - 164, The query parameter name is inconsistent across the mcp deployment handlers: `gatewayId` is still being read in the undeploy/restore and list paths even though validation and the DTO now use `gatewayHandle`. Update the relevant `r.URL.Query().Get(...)` calls in the affected handler functions to read `gatewayHandle` consistently, and keep the existing required-field checks and filter logic aligned with that same symbol so requests using the new name work everywhere.platform-api/src/internal/handler/mcp.go (1)
229-231: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Return a 401-shaped error body here.
Line 231 sends
StatusUnauthorized, but the payload still says400 / Bad Request, so clients receive conflicting error metadata.Proposed fix
- httputil.WriteJSON(w, http.StatusUnauthorized, utils.NewErrorResponse(400, "Bad Request", "MCP server returned 401 Unauthorized. Check the provided credentials.")) + httputil.WriteJSON(w, http.StatusUnauthorized, utils.NewErrorResponse(401, "Unauthorized", "MCP server returned 401 Unauthorized. Check the provided credentials."))📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.case errors.Is(err, constants.ErrMCPServerUnauthorized): h.slogger.Error("MCP server returned 401 Unauthorized", "error", err, "inputUrl", req.Url) httputil.WriteJSON(w, http.StatusUnauthorized, utils.NewErrorResponse(401, "Unauthorized", "MCP server returned 401 Unauthorized. Check the provided credentials."))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@platform-api/src/internal/handler/mcp.go` around lines 229 - 231, The MCP unauthorized handling in the relevant error branch of mcp.go is returning a 401 status with a 400/Bad Request payload, which creates conflicting response metadata. Update the `errors.Is(err, constants.ErrMCPServerUnauthorized)` path in the MCP handler to build a 401-shaped error body that matches `http.StatusUnauthorized`, and keep the response message aligned with unauthorized/credential failure semantics. Use the existing `httputil.WriteJSON` and `utils.NewErrorResponse` call sites in `mcp.go` to ensure the status code and payload agree.
| subscriberId: | ||
| type: string | ||
| minLength: 1 | ||
| description: Unique subscriber identifier for the subscription (required) | ||
| example: "user-123" | ||
| applicationId: | ||
| type: string | ||
| description: Application ID (from DevPortal/STS). Optional in token-based subscriptions. | ||
| example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890" | ||
| description: Application handle. Optional in token-based subscriptions. |
Contributor
Author
There was a problem hiding this comment.
breaking UIs
| @@ -8345,21 +8205,21 @@ components: | |||
| properties: | |||
| apiId: | |||
| type: string | |||
| description: API handle or UUID (REST API identifier) | |||
| example: "c9f2b6ae-1234-5678-9abc-def012345678" | |||
| description: REST API handle | |||
Contributor
There was a problem hiding this comment.
Is this the Rest API handle or the Artifact handle?
BTW, we may need to include Kind as well, if we are not going with UUID
| @@ -586,7 +586,7 @@ paths: | |||
| '500': | |||
| $ref: '#/components/responses/InternalServerError' | |||
|
|
|||
| /rest-apis/{apiId}: | |||
| /rest-apis/{apiHandle}: | |||
Contributor
There was a problem hiding this comment.
Shall we go with just {id}
Suggested change
| /rest-apis/{apiHandle}: | |
| /rest-apis/{id}: |
Contributor
There was a problem hiding this comment.
Yeah, in general "id" is what we use to fetch a resource. handle or whatever the representation of the id is an internal detail.
This was done because of an entry in the guideline? We should fix the guideline if its the case.
Contributor
There was a problem hiding this comment.
Lets keep this until we come to a conclusion and change altogether
Thushani-Jayasekera
marked this pull request as draft
June 28, 2026 11:06
Contributor
Author
|
closing this PR as this was handled through a different PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Relates to #2288