Skip to content

Handle unions of single-item enums #178

Description

@david-crespo

In 59c40a1 we pull in changes from the following chain of PRs:

oxidecomputer/omicron#1789
oxidecomputer/dropshot#454
GREsau/schemars#152

In short, a schemars fix to put doc comments on enum variants caused dropshot to change some simple enum schemas to oneOfs of single-item enums, changing this

oxide.ts/client/Api.ts

Lines 519 to 530 in 45ead9d

export const InstanceState = z.enum([
"creating",
"starting",
"running",
"stopping",
"stopped",
"rebooting",
"migrating",
"repairing",
"failed",
"destroyed",
]);

to this

oxide.ts/client/Api.ts

Lines 520 to 531 in 59c40a1

export const InstanceState = z.union([
z.enum(["creating"]),
z.enum(["starting"]),
z.enum(["running"]),
z.enum(["stopping"]),
z.enum(["stopped"]),
z.enum(["rebooting"]),
z.enum(["migrating"]),
z.enum(["repairing"]),
z.enum(["failed"]),
z.enum(["destroyed"]),
]);

Fortunately the inferred type ends up the same, and I think in practice the runtime behavior is also the same. So we don't necessarily have to convert this back to what it was before, though it would be neater. It would be nice to pull in the newly available comments on each variant, though.

https://github.com/oxidecomputer/omicron/blob/74f3ca89af11b0ce6d9f9bd4b5bdcbeb04d1ba3e/openapi/nexus.json#L9098-L9114

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions