Tags

[sjmiller609]

Summary

• add shared lib/tags package for strict metadata validation, cloning, and filter matching
• expand OpenAPI + generated OAPI types with reusable MetadataTags schema and metadata filters across mutable resources
• wire metadata create/get/list/filter behavior for instances, snapshots, images, volumes, devices, ingresses, and builds
• parse createBuild multipart metadata field as JSON object
• add focused metadata roundtrip tests for tags/snapshot/images/volumes/ingress/builds/devices

Validation

• make oapi-generate
• go test ./lib/tags
• go test ./lib/snapshot -run 'TestStoreSaveLoadListDelete|TestListSnapshotsFilterMatches'
• go test ./lib/images -run TestImageMetadataToImage
• go test ./lib/volumes -run TestCreateVolume_MetadataRoundTrip
• go test ./lib/ingress -run TestCreateIngress_MetadataRoundTrip
• go test ./lib/builds -run TestBuildMetadataReadWrite_MetadataRoundTrip
• go test ./lib/instances -run 'TestListInstancesFilter|TestCloneStoredMetadataForFork_DeepCopiesReferenceFields|TestCreateSnapshot'

Notes

• full go test ./... includes unrelated platform/environment-specific failures in this environment (e.g. VZ lifecycle tests and existing cross-platform device test compilation constraints).

---

Note

Medium Risk
Cross-cutting API and persistence changes add/validate metadata on multiple resource types and modify generated OAPI client/server method signatures for list endpoints. Main risk is backward-compatibility (new 400s for invalid metadata and updated client call sites) rather than core security logic.

Overview
Introduces a shared lib/tags package (Validate, Clone, Matches) and adopts tags.Metadata across builds, devices, images, ingresses, instances, snapshots, and volumes, including persistence and deep-copy behavior.

Expands openapi.yaml/generated lib/oapi with a reusable MetadataTags schema, adds metadata fields to request/response models, and adds metadata query filtering (deepObject) to list endpoints—updating generated client/server interfaces to take *List*Params.

Updates API handlers/managers to accept, validate, store, return, and filter by metadata (including parsing CreateBuild multipart metadata JSON), and returns 400 invalid_request for invalid metadata; adds focused round-trip tests covering metadata storage/cloning and filter matching.

^{Written by Cursor Bugbot for commit 358a2c0. This will update automatically on new commits. Configure here.}

[github-actions]

✱ Stainless preview builds

This PR will update the hypeman SDKs with the following commit message.

feat: Add strict metadata tags across mutable resources

✅ hypeman-openapi studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅

⚠️ hypeman-typescript studio · code

Your SDK build had at least one "error" diagnostic.
generate ❗ → build ✅ → lint ✅ → test ✅

npm install https://pkg.stainless.com/s/hypeman-typescript/968bb7c4dc2843612c943024033fbfd32f4ea771/dist.tar.gz

✅ hypeman-go studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅ → build ⏭️ → lint ✅ → test ✅

go get github.com/stainless-sdks/hypeman-go@8b5543e6f8fed7062d28c37fa35ba031e14c6f79

---

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-03-07 18:34:02 UTC

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Risk assessment: Medium-High.

Reasoning from diff scope:

• Cross-cutting production behavior changes across multiple core resource paths (instances, snapshots, images, volumes, devices, ingress, builds).
• New shared metadata validation/matching package (lib/tags) wired into create/list/get flows, including request validation and filtering semantics.
• API contract expansion in openapi.yaml and large generated lib/oapi/oapi.go update increases client/server compatibility surface.
• Non-trivial blast radius (43 files, ~1.3k insertions) with user-facing query/filter behavior changes.

Decision:

• Review is required; I did not approve this PR.
• Requested reviewers: @rgarcia, @hiroTamada.

---

  

[sjmiller609]

Closes: #126

[rgarcia]

wondering if we should name this field tags instead of metadata since we already use metadata (at least internally) when talking about instance metadata stored on disk

the counterpoint is that i've never been a fan of the name tags in AWS because i think of tags as a set<string> not map[string]string, but maybe this is just me