#367 Missing 'parent' field in GlobalArgsSchema for several @swamp/gcp/* models causes get to fail

Summary

Several @swamp/gcp/* extension models (auto-generated) reference g["parent"] in their get (and create/update/delete) method implementations, but parent is not declared in the corresponding GlobalArgsSchema. Runtime validation rejects setting parent in globalArguments:

Global arguments validation failed: Unknown argument(s): parent.
Valid arguments are: annotations, binaryAuthorization, ..., serviceId, location

This makes it impossible to use get to fetch an existing GCP resource that needs a parent path (project + location). The same pattern is present in the other affected models' create methods, so I expect it to break create and delete similarly.

Affected extensions and models (versions current as of 2026-05-16)

• @swamp/gcp/[email protected] — services
• @swamp/gcp/[email protected] — secrets
• @swamp/gcp/[email protected] — connections, connections-repositories
• @swamp/gcp/[email protected] — repositories
• @swamp/gcp/[email protected] — keyrings

The pattern is shared across all the auto-generated GCP extension models, so it likely affects more model types beyond the five I happen to have hit during a real inventory exercise.

Reproduction

swamp extension pull @swamp/gcp/run
swamp model create @swamp/gcp/run/services my-test
# edit the YAML to add:
#   globalArguments:
#     parent: projects/<your-project>/locations/us-central1
swamp model method run my-test get --input identifier=some-existing-service

Expected: get succeeds and writes the service's state to the model's data store.

Actual:

{
  "error": "Global arguments validation failed: Unknown argument(s): parent. Valid arguments are: annotations, binaryAuthorization, buildConfig, client, clientVersion, customAudiences, defaultUriDisabled, description, iapEnabled, ingress, invokerIamDisabled, labels, launchStage, multiRegionSettings, name, scaling, template, terminalCondition, traffic, serviceId, location",
  "code": "method_execution_failed"
}

Code reference

In each affected model's get method (the path is the same in every model; here is @swamp/gcp/run/models/services.ts):

get: {
  ...
  execute: async (args, context) => {
    const g = context.globalArgs;
    const params = { project: projectId };
    params["name"] = buildResourceName(String(g["parent"] ?? ""), args.identifier);
    ...
  }
}

But GlobalArgsSchema in the same file does not declare a parent field. The Zod schema rejects the field at validation time, so the ??"" fallback always wins and buildResourceName produces a malformed name.

Workaround in use

We hand-patched .swamp/bundles/<hash>/<model>.js for each affected model to insert parent: z.string().describe("The parent resource path").optional(), at the top of the GlobalArgsSchema. This works at runtime but is lost on any swamp extension install because the bundles are regenerated from the registry sources.

Proposed fix

Add to each affected model's GlobalArgsSchema:

parent: z.string().describe("The parent resource path, e.g. projects/{project}/locations/{location}").optional(),

Alternatively, derive parent from existing fields where applicable (location, serviceId, etc.), but adding parent as an explicit optional field is the smaller, more compatible change.

Why this matters

This blocks the inventory / replication use case where existing GCP resources need to be brought under swamp management without re-creating them. get is the standard read-only path for that and is hit on every adopted resource.

Environment

• swamp version: 20260515.175436.0-sha.2f8e98af
• Linux x86_64

Upstream repository: https://github.com/systeminit/swamp-extensions

Environment

• Extension: @swamp/gcp/[email protected]
• swamp: 20260515.175436.0-sha.2f8e98af
• OS: linux (x86_64)
• Deno: 2.7.14+19bd3d8
• Shell: /bin/bash