CatalogData declares `class`/`snapshotURL`; every server emits `contentClass`/`imageURL`

[simihablo]

Summary

CatalogData (schemas/constructs/v1beta2/catalog/catalog.yaml, referenced by the v1beta3 design construct as MesheryPattern.catalogData) names two fields that no server ever emits, and omits the two that every server does emit. With additionalProperties: false on the same object, the canonical schema does not describe - and would reject - the payload that is actually on the wire.

What the wire carries

Both servers marshal catalogData from meshkit's models/catalog/v1alpha1.CatalogData:

• meshery-cloud: server/models/meshery_patterns.go -> CatalogData *v1alpha1.CatalogData \json:"catalogData" db:"catalog_data"``
• the same meshkit type backs the Meshery server side.

meshkit/models/catalog/v1alpha1/catalog.go:

type CatalogData struct {
    ContentClass     ContentClass               `json:"contentClass,omitempty"`
    PublishedVersion string                     `json:"publishedVersion"`
    Compatibility    []CatalogDataCompatibility `json:"compatibility"`
    PatternCaveats   string                     `json:"patternCaveats"`
    PatternInfo      string                     `json:"patternInfo"`
    // Contains reference to the dark and light mode snapshots of the catalog.
    SnapshotURL []string `json:"imageURL,omitempty"` // ... updated the json tag to match previous key name, so changes will not be required in existing catalogs
    Type        CatalogDataType `json:"type"`
}

Note the explicit comment on SnapshotURL: the JSON tag was deliberately held at the legacy imageURL key so stored catalog rows would not need rewriting.

meshery-cloud queries the stored JSONB by that name too - server/dao/meshery_patterns_dao.go:

// All rows backfilled to canonical `contentClass`
finalWhere, args := utils.GenerateWhereClause("LOWER(catalog_data->>'contentClass') = LOWER(?)", catalogClasses)

What the canonical declares

schemas/constructs/v1beta2/catalog/catalog.yaml declares class and snapshotURL, and sets additionalProperties: false.

wire key (meshkit, both servers)	canonical key
contentClass	class
imageURL	snapshotURL

Blast radius

1. Any consumer that types catalogData from @meshery/schemas reads class / snapshotURL and gets undefined. Sistent's catalog cards, catalog detail page and performers section all read contentClass / imageURL and are therefore correct against the wire and wrong against the canonical - see chore(deps): bump js-yaml from 4.2.0 to 4.3.1 layer5io/sistent#1780, which keeps a deliberately narrower local PatternCatalogData pending this issue.
2. additionalProperties: false means a strict validator run against a real catalog payload rejects it on two unknown properties.

Two related inconsistencies in the same construct

a) The class enum disagrees with contentClass elsewhere in this repo. CatalogData.class allows official | verified | reference architecture, while the catalog-content constructs generated into constructs/v1beta3/design/Design.d.ts and cloudApi.d.ts type contentClass as official | verified | project | community. Same concept, two enums, neither a subset of the other.

b) The generated Go models disagree with the YAML. models/v1beta1/catalog/catalog.go and models/v1alpha2/catalog/catalog.go tag pattern_caveats / pattern_info in snake_case, while the YAML (and the emitted TypeScript, and the wire) use patternCaveats / patternInfo. So this single construct currently has three disagreeing representations inside meshery/schemas itself.

Suggested resolution

Rename class -> contentClass and snapshotURL -> imageURL in constructs/v1beta2/catalog/catalog.yaml to match the wire, reconcile the two contentClass enums, and regenerate so the Go models stop emitting pattern_caveats / pattern_info. If instead the intent is for the servers to move to class / snapshotURL, that needs a dual-accept window in meshkit first, because the stored catalog_data JSONB rows use the legacy keys and are queried by them.

Filed from the sistent schema-consumer audit (layer5io/sistent#1780).