MCP Setup Wizard: Gateway created in Step 1 is not selectable as HTTPRoute parentRef in Step 2

[Anton-Fil]

---

Component

src/components/mcp/ — MCP Management setup wizard

Summary

In the MCP Setup Wizard, all resources (Gateway, HTTPRoute, ReferenceGrant, MCPGatewayExtension) are created only at the final Verify step (Step 4). Because of this, a Gateway that the user chooses to create in Step 1 does not yet exist in the cluster when they reach Step 2 (Route for Gateway). The embedded HTTPRoute create form populates its parentRef selector from a live cluster watch, so the just-defined Gateway is missing from the dropdown and cannot be selected as the route's parent — which is the whole point of the wizard flow.

Steps to Reproduce

1. Go to MCP Management with no existing MCPGatewayExtension → land on the Get started empty state.
2. Click MCP gateway setup wizard (/kuadrant/mcp/setup-wizard).
3. Step 1: choose Create a new Gateway, fill in a name (e.g. my-mcp-gw).
4. Step 2: choose Create a new HTTPRoute and open the parentRef selector.
5. The Gateway my-mcp-gw from Step 1 is not in the list of selectable parents.

Expected

The Gateway defined in Step 1 should be selectable as the HTTPRoute's parentRef in Step 2.

Actual

The Step 1 Gateway is absent from the parentRef selector because it is only created at Step 4 (Verify).

Root Cause

• MCPSetupWizard.tsx collects new resources into verifyItems (newGatewayResource, newRouteResource, etc.) and defers all k8sCreate calls to MCPVerifyStep.tsx (Step 4).
• The Step 2 HTTPRoute form is the embedded HTTPRouteCreatePage, whose parent selector (GatewaySelect / ParentReferencesSelect) reads Gateways via useK8sWatchResource (live cluster state) — see GatewaySelect.tsx:44.
• Since the Step 1 Gateway hasn't been persisted yet, the watch never returns it.

Proposed Solution

Rework the wizard so the Gateway is created during Step 1 (on "Next"), rather than deferred to the Verify step. Once persisted, the live watch in Step 2 will surface it as a selectable parentRef automatically.

Design points to resolve during implementation:

• Create-on-advance: when gatewayMode === 'new', call k8sCreate for the Gateway when leaving Step 1; block advancing on failure and surface the error inline. Do the same for other steps that later depend on the created resource (Step 2 route → Step 3 extension listeners).
• Remove the created Gateway from verifyItems so Step 4 doesn't attempt to create it twice.
• Idempotency / back-navigation: if the user goes back to Step 1 and clicks Next again, don't recreate/duplicate the Gateway (track "already created" state; consider update vs. create).
• Partial-failure / cancel cleanup: decide behavior if the user cancels or a later step fails after the Gateway is already created (leave it, or offer rollback). Document the chosen behavior.
• Consistency: consider applying the same "create-as-you-go" model to the HTTPRoute in Step 2 so Step 3's listener/section selection also reflects real state. Alternatively, keep the extension in Verify since nothing downstream depends on it existing mid-wizard.
• Tests: update MCPVerifyStep.test.tsx and add wizard-flow coverage for create-on-advance, back-navigation idempotency, and error handling.

Affected Files

• src/components/mcp/MCPSetupWizard.tsx (step orchestration, verifyItems)
• src/components/mcp/MCPVerifyStep.tsx (currently owns all creation)
• src/components/httproute/HTTPRouteCreatePage.tsx / GatewaySelect.tsx (parentRef source — no change expected, but relevant context)

Notes / Open Questions

• Should this apply to MCPRegistrationWizard.tsx too, or only the setup wizard?
• Preferred UX for a step that creates a resource: block on "Next" until create succeeds, or create in the background with a spinner?

---