Skip to content

Preserve minItems and string format metadata in the Rust model and plugin API #47

Closed

Description

@petebacondarwin

Split from #33 after checking the Rust implementation at 7d40705fb61e7eedfe62e547348e0b291555739d.

The Rust model preserves nested oneOf branches, branch-specific required fields, closed-object information, and array maxItems. cf can consume these to validate bodies assembled from flags. Two constraints from the original example still disappear before a plugin can use them: array minItems and the original string format, including uuid.

Reproduction

Pass this property through the Rust parser and inspect it from a WASM plugin:

{
  "dataset_ids": {
    "type": "array",
    "minItems": 1,
    "maxItems": 50,
    "items": { "type": "string", "format": "uuid" }
  }
}

The plugin sees an array with maxItems: 50 whose element is plain scalar: "string". It has no minimum-length or UUID-format metadata. Consequently a CLI consumer cannot derive rejection of an empty array or a non-UUID string from this model, even after fixing nested-union selection in cf.

Current implementation

  • SchemaObject stores max_items, but no min_items.
  • Scalar::String deliberately includes formats such as uuid without retaining the original format.
  • The plugin interface likewise exposes only max-items for arrays and no original string-format metadata.

Expected behavior

Preserve array minItems and the original string format in the Rust model, WASM interface, and TypeScript plugin API, so consumers can choose how to validate them. Keep the distinction between an absent bound/format and an explicit value, including minItems: 0.

Add parser and plugin round-trip regression coverage for minItems: 0, minItems: 1, maxItems: 50, and string format: "uuid", including nested properties and referenced schemas. The acceptance case should give a CLI consumer enough information to reject an empty dataset_ids array and invalid UUID items while accepting 1–50 valid UUIDs.

This issue concerns missing metadata, rather than adding product-specific validation or reviving the removed TypeScript resolver. The branch-selection and closed-branch validation from #33 can be implemented generically in cf using the information Rust already exposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions