feat: add catalog gateway actions - #81
Conversation
| message: string; | ||
| } | ||
|
|
||
| const DISCONNECT_POLL_TIMEOUT_MS = 60_000; |
There was a problem hiding this comment.
60-second timeout may be too long for user experience, it's a looong wait before before seeing timeout error. Consider shorter timeout with retry option:
const DISCONNECT_POLL_TIMEOUT_MS = 30_000; // 30 secondsThen, In error handling:
setRegistrationNotification({
type: "error",
message: intl.formatMessage(
{ id: "mcpServer.catalog.disconnectPending" },
{ name: server.name }
),
action: {
label: intl.formatMessage({ id: "mcpServer.catalog.retry" }),
onClick: () => void handleDisconnect(server)
}
});
marekdano
left a comment
There was a problem hiding this comment.
🚫 Blocking
- Shared abort ref cancels wrong server's disconnect
src/pages/ServerCatalog.tsx:607
disconnectPollAbortRef is one page-wide ref, not scoped per server. Retrying server A's timed-out disconnect while disconnecting server B aborts A's poll silently — A's disconnect state is abandoned client-side even if the backend delete is still pending.
- Impact preview gated on wrong permission
src/pages/ServerCatalog.tsx:496
Gateway impact preview before disconnect checkscanTest(read permission) instead of delete-relevant access, so a user who can delete but not read a gateway never sees which virtual servers are affected before confirming a destructive action.
⚠️ Major
- Disconnect notification overwritten across servers
src/pages/ServerCatalog.tsx:595
An unresolved "still disconnecting — Retry" notification for server A is silently clobbered if the user disconnects server B next, losing the only way to follow up on A.
testSuccess/testFailurestrings are identical
src/i18n/locales/en-US/mcpServer.json:104(same in es-ES, pt-BR)
Success and failure connectivity-test messages read the same text — colorblind or screen-reader users can't tell a passed test from a failed one.
🟡 Minor
- Persistent poll errors read as ordinary timeouts
src/pages/ServerCatalog.tsx:530
waitForCatalogDisconnect treats every refetch failure as transient, so a real backend error (403/500) during polling looks identical to normal slowness — the user just sees "still disconnecting" forever.
💡 Suggestion
- Duplicate
DELETE /gateways/{id}implementation
src/api/catalog.ts:26
disconnectCatalogGatewayre-implements whatserversApi.deletealready does, just to get status/headers viadeleteWithMeta. Two places to keep in sync on backend contract changes.
|
Disconnect blocks dismissal for the length of the poll. Impact preview failure renders identically to no impact. The catch sets "Still disconnecting" is styled as a failure. Focus lands on
Nothing on the card indicates that test or disconnect is running. The |
|
Disconnect visual reference added. |
| import { useEffect, useId, useRef, useState } from "react"; | ||
| import type { ReactNode } from "react"; | ||
| import { CircleCheck, EllipsisVertical, FileText, Plus } from "lucide-react"; | ||
| import { CircleCheck, EllipsisVertical, FileText, PlugZap, Plus, Unplug } from "lucide-react"; |
|
Thanks @a-effort and @marekdano for the review. updated screenshots
Please review when you get a chance |
marekdano
left a comment
There was a problem hiding this comment.
All issues addressed!
LGTM 🚀
Signed-off-by: Vishu Bhatnagar <vishu.bhatnagar@ibm.com>
Signed-off-by: Vishu Bhatnagar <vishu.bhatnagar@ibm.com>
Signed-off-by: Vishu Bhatnagar <vishu.bhatnagar@ibm.com>
Signed-off-by: Vishu Bhatnagar <vishu.bhatnagar@ibm.com>
Signed-off-by: Vishu Bhatnagar <vishu.bhatnagar@ibm.com>
Signed-off-by: Vishu Bhatnagar <vishu.bhatnagar@ibm.com>
Signed-off-by: Vishu Bhatnagar <vishu.bhatnagar@ibm.com>
1ca3e4b to
a42271e
Compare
Signed-off-by: Vishu Bhatnagar <vishu.bhatnagar@ibm.com>



Summary
Validation