feat: convert single-value enums to const for base types

[pengying]

Convert single-value enums to const for base types

This PR replaces single-value enums with const properties throughout the OpenAPI schema. This change improves schema clarity and validation behavior.

Additionally, the PR flattens the LightningExternalAccountInfo schema structure, converting it from a complex nested structure with allOf and oneOf combinations to a simpler flat object with optional properties.

[pengying]

• feat: add Stainless SDK config and misc cleanups #132
• feat: rename Error to GridError and add additionalProperties to error schemas #131
• feat: add Customer API discriminators and consolidate customer changes #130
• feat: add Quote/Transaction discriminators and remove inline examples #129
• feat: add isPlatformAccount to PaymentInstructions and remove PaymentAccountOrWalletInfo refs #128
• feat: rename accounts to data in list external accounts response #127
• feat: convert single-value enums to const for base types #126 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR converts single-value enums to const properties across 39 files and flattens the LightningExternalAccountInfo schema structure.

Enum to const conversions - The majority of changes (38 files) replace single-value enum arrays with const for discriminator properties like accountType, beneficiaryType, customerType, eventType, and status. These changes are semantically correct and improve schema clarity.

LightningExternalAccountInfo flattening - The schema was restructured from an allOf + oneOf composition to a flat object. The description states "Exactly one of invoice, bolt12, or lightningAddress must be provided," but the schema no longer enforces this constraint. The previous oneOf structure ensured mutual exclusion at the schema level, while the flattened version makes all three fields optional with no validation preventing invalid states (zero fields set, or multiple fields set simultaneously).

Confidence Score: 2/5

• Breaking change in LightningExternalAccountInfo removes critical validation logic
• The enum to const conversions (38/39 files) are safe improvements. However, the LightningExternalAccountInfo schema change removes the oneOf constraint that previously enforced mutual exclusion between payment destination fields. This allows the API to accept invalid requests with zero or multiple payment destinations set, which could lead to runtime errors or undefined behavior.
• openapi/components/schemas/external_accounts/LightningExternalAccountInfo.yaml requires verification that validation is handled elsewhere (application-level or additional schema constraints)

Important Files Changed

Filename	Overview
openapi/components/schemas/external_accounts/LightningExternalAccountInfo.yaml	Flattened schema from allOf/oneOf structure to simple object, removing mutual exclusion validation for payment destination fields
openapi/components/schemas/errors/Error400.yaml	Converted single-value status enum to const (400)
openapi/components/schemas/errors/Error412.yaml	Converted single-value status and code enums to const (412, UNSUPPORTED_UMA_VERSION)
openapi/components/schemas/common/BaseWalletInfo.yaml	Converted single-value accountType enum to const (BASE_WALLET)
openapi.yaml	Built OpenAPI spec with all enum to const conversions and LightningExternalAccountInfo flattening

Sequence Diagram

sequenceDiagram
    participant Client
    participant API
    participant Validator
    participant Schema
    
    Note over Client,Schema: Enum to Const Conversion Flow (38 files)
    Client->>API: POST request with accountType
    API->>Validator: Validate request body
    Validator->>Schema: Check accountType value
    alt Before: enum with single value
        Schema-->>Validator: Must be one of [LIGHTNING]
    else After: const value
        Schema-->>Validator: Must equal LIGHTNING
    end
    Validator-->>API: ✓ Same validation result
    API-->>Client: Response
    
    Note over Client,Schema: LightningExternalAccountInfo Flow
    Client->>API: POST /external-accounts (Lightning)
    API->>Validator: Validate Lightning account
    Validator->>Schema: Check payment destination
    alt Before: oneOf constraint
        Schema-->>Validator: Require exactly one of: invoice, bolt12, lightningAddress
        alt Invalid: zero fields
            Validator-->>API: ✗ Validation error
        end
        alt Invalid: multiple fields
            Validator-->>API: ✗ Validation error
        end
        alt Valid: exactly one field
            Validator-->>API: ✓ Valid
        end
    else After: flattened optional fields
        Schema-->>Validator: All fields optional (no mutual exclusion)
        alt Zero fields set
            Validator-->>API: ✓ Passes schema validation
            Note right of API: Runtime error likely
        end
        alt Multiple fields set
            Validator-->>API: ✓ Passes schema validation
            Note right of API: Undefined behavior
        end
    end
    API-->>Client: Response or error

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}