models.Deployment.ProviderConfig is a models.JSONObject, but this assigns a map[string]any (input.Body.ProviderConfig). Go won’t allow assigning a plain map to a distinct named map type, so this should be converted (or the field type adjusted) before constructing deploymentReq.

cleanupExistingDeployment decides whether to run Kubernetes runtime cleanup based on the incoming platform argument rather than the platform of the existing deployment being removed. If a stale record belongs to a different provider/platform than the new request, this can either skip necessary Kubernetes cleanup (leaking resources) or attempt Kubernetes deletes for a non-Kubernetes deployment. Consider resolving the platform from existing.ProviderID (similar to removeDeploymentRecord) instead of using the caller-provided platform.

deploymentResourceIndex calls registry.GetDeployments(ctx, nil) (no filter) and builds an index over all deployments on every servers/agents request that attaches deployment metadata. This can become a scalability bottleneck as the deployments table grows. If possible, narrow the query to the relevant resource type and names for the current response (or add a targeted DB/API method) to avoid full-table reads per request.

This test name suggests inactive statuses are filtered out, but the assertions expect both a deployed and a cancelled deployment to be present in the index. Renaming the test to reflect the actual behavior would make the intent clearer.

deploymentResourceIndex sorts summaries by UpdatedAt, but in this test both deployments have zero UpdatedAt values. Since slices.SortFunc is not stable, relying on the original order (and asserting [0]/[1] IDs) can be flaky. Set distinct UpdatedAt timestamps in the fixtures or assert order-insensitively.

registry.CreateDeployment can return database.ErrInvalidInput for multiple reasons (e.g., missing/unsupported platform adapter). Mapping all ErrInvalidInput cases to a generic "Invalid deployment request" makes unsupported provider/platform failures hard to diagnose. Consider returning a more specific error message/status when the platform isn’t supported vs. when the request body is invalid.

if we're not using the ID, does that mean I can only deploy an artifact once -- like one MCPServer or Agent deployment in kubernetes?

yes although this is already the existing behavior; current db shape still enforces single-row identity from legacy semantics (not ID semantics). supporting parallel deployments across providers would require a schema + service semantics change (we can leave this for the post-api phase of the refactor)

CREATE TABLE deployments (
    -- Primary identifiers
    server_name VARCHAR(255) NOT NULL,
    version VARCHAR(255) NOT NULL,
    ...
    -- Primary key
    CONSTRAINT deployments_pkey PRIMARY KEY (server_name, version)
);

would it make sense to extract these two functions to a common place, since they are more or less the same as the one in agent list?

these two functions are exactly the same

are we not cleaning these up anymore?

please make sure this scenario works:

1. deploy an agent to k8s (arctl agent deploy)
2. manually delete the agent from k8s
3. deploy the agent again to k8s (arctl agent deploy)

we no longer do name/version cleanup on deploy, because that breaks once multiple deployments can exist for the same registry artifact. deployments are now 1:1 by deployment ID, and k8s resources are named/labeled with that ID.

for your scenario (deploy -> manually delete in k8s -> deploy again), this should work. redeploy creates a new deployment ID and does not collide with previous runtime state.

note that deleting the deployment from the DB if it is deleted directly from k8s will require a follow up PR (as we discussed to implement db reconciliation feature)

i plan to address this once the api refactor is done