feat: fixing transaction schema

[pengying]

TL;DR

Fixed transaction schema inheritance by implementing proper polymorphic type handling for transactions.

What changed?

• Removed the type property from the base Transaction schema to avoid conflicts when merging with child schemas
• Added required type property with specific enum values to both IncomingTransaction and OutgoingTransaction schemas
• Created a new TransactionOneOf schema that uses proper polymorphic discrimination between transaction types
• Updated all API endpoints to reference TransactionOneOf instead of the base Transaction schema
• Reorganized schema definitions for better clarity and proper inheritance

How to test?

1. Verify that transaction-related API endpoints return the correct schema based on transaction type
2. Confirm that the OpenAPI documentation correctly shows the discriminated transaction types
3. Test both incoming and outgoing transaction flows to ensure proper type handling

Why make this change?

The previous schema structure had conflicting type definitions when the base Transaction schema was merged with specific transaction type schemas through allOf. This change implements proper polymorphic inheritance using the oneOf discriminator pattern, ensuring that transaction types are correctly differentiated and validated. This prevents potential issues with schema validation and improves API documentation clarity.

[pengying]

• fix: correcting resource id names #208
• feat: fixing transaction schema #207 👈 (View in Graphite)
• main

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

[github-actions]

✱ Stainless preview builds

This PR will update the grid SDKs with the following commit messages.

kotlin

feat(api): add type discriminators to transactions, union response types for operations

openapi

fix(types): add discriminated union to transfer-in/transfer-out/transactions responses

python

fix(types): update return types in transfer_in/transfer_out/transactions

typescript

feat(api): add response types to transferIn/transferOut/transactions methods

Edit this comment to update them. They will appear in their respective SDK's changelogs.

✅ grid-openapi studio · code · diff

Your SDK built successfully.
generate ✅

✅ grid-python studio · code · diff

Your SDK built successfully.
generate ✅ → build ✅ → lint ✅ → test ✅

pip install https://pkg.stainless.com/s/grid-python/1bced3e0b6dc204e757c27c0f1087d1ff90f277d/grid-0.0.1-py3-none-any.whl

✅ grid-typescript studio · code · diff

Your SDK built successfully.
generate ✅ → build ✅ → lint ✅ → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/cbf123fa2d6dc1122b9a154a055231cb7ce1ef3c/dist.tar.gz

✅ grid-kotlin studio · code · diff

Your SDK built successfully.
generate ✅ → build ✅ → lint ✅ → test ✅

New diagnostics (7 note)

💡 Schema/EnumHasOneMember: This enum schema has just one member, so it could be defined using [`const`](https://json-schema.org/understanding-json-schema/reference/const).

💡 Schema/EnumHasOneMember: This enum schema has just one member, so it could be defined using [`const`](https://json-schema.org/understanding-json-schema/reference/const).

💡 Schema/EnumHasOneMember: This enum schema has just one member, so it could be defined using [`const`](https://json-schema.org/understanding-json-schema/reference/const).

💡 Schema/EnumHasOneMember: This enum schema has just one member, so it could be defined using [`const`](https://json-schema.org/understanding-json-schema/reference/const).

💡 Schema/EnumHasOneMember: This enum schema has just one member, so it could be defined using [`const`](https://json-schema.org/understanding-json-schema/reference/const).

💡 Schema/EnumHasOneMember: This enum schema has just one member, so it could be defined using [`const`](https://json-schema.org/understanding-json-schema/reference/const).

💡 Schema/EnumHasOneMember: This enum schema has just one member, so it could be defined using [`const`](https://json-schema.org/understanding-json-schema/reference/const).

---

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-02-19 01:34:02 UTC

[greptile-apps]

Greptile Summary

This PR refactors the transaction schema to implement proper polymorphic type handling using the OpenAPI oneOf discriminator pattern. The changes resolve conflicts that occurred when the base Transaction schema's type property merged with child schemas through allOf.

Key changes:

• Created TransactionOneOf schema as a polymorphic wrapper using oneOf with discriminator on the type field
• Added explicit type property with specific enum values (INCOMING or OUTGOING) to both child transaction schemas
• Updated all transaction-related API endpoints to reference TransactionOneOf instead of Transaction
• Added stainless.yml configuration to remove the type property from the base schema during SDK generation
• Enhanced TransactionStatus documentation with a descriptive table
• Removed paymentInstructions from OutgoingTransaction's required fields (it was already optional in properties)
• Reorganized schema definitions in bundled files for better clarity

Impact:
The refactoring improves schema validation, ensures correct type discrimination between incoming and outgoing transactions, and provides clearer API documentation. The oneOf pattern is the standard approach for polymorphic schemas in OpenAPI 3.x.

Confidence Score: 5/5

• This PR is safe to merge with no issues found
• The schema refactoring follows OpenAPI best practices for polymorphic types using the oneOf discriminator pattern. All changes are internally consistent, the bundled specs were properly regenerated with make build, and the approach correctly addresses the stated problem of conflicting type definitions in allOf merges. The stainless.yml configuration appropriately handles SDK generation requirements.
• No files require special attention

Important Files Changed

Filename	Overview
.stainless/stainless.yml	Added removal rule for type property in Transaction base schema to prevent conflicts during SDK generation
openapi/components/schemas/transactions/IncomingTransaction.yaml	Added required type field with INCOMING enum value for proper polymorphic discrimination
openapi/components/schemas/transactions/OutgoingTransaction.yaml	Added required type field with OUTGOING enum, removed paymentInstructions from required fields
openapi/components/schemas/transactions/TransactionOneOf.yaml	New schema implementing proper oneOf polymorphic pattern with discriminator for transaction types
openapi/components/schemas/transactions/TransactionStatus.yaml	Enhanced documentation with descriptive table for each transaction status value

Class Diagram

%%{init: {'theme': 'neutral'}}%%
classDiagram
    class Transaction {
        +string id
        +TransactionStatus status
        +string type
        +TransactionDestination destination
        +string customerId
        +string platformCustomerId
        +datetime settledAt
        +datetime createdAt
        +datetime updatedAt
        +string description
        +CounterpartyInformation counterpartyInformation
    }
    
    class TransactionOneOf {
        <<oneOf>>
        discriminator: type
    }
    
    class IncomingTransaction {
        +string type = "INCOMING"
        +TransactionSource source
        +CurrencyAmount receivedAmount
        +ReconciliationInstructions reconciliationInstructions
        +IncomingRateDetails rateDetails
        +IncomingTransactionFailureReason failureReason
    }
    
    class OutgoingTransaction {
        +string type = "OUTGOING"
        +TransactionSource source
        +CurrencyAmount sentAmount
        +CurrencyAmount receivedAmount
        +number exchangeRate
        +integer fees
        +string quoteId
        +PaymentInstructions[] paymentInstructions
        +Refund refund
        +OutgoingRateDetails rateDetails
        +OutgoingTransactionFailureReason failureReason
    }
    
    Transaction <|-- IncomingTransaction : extends via allOf
    Transaction <|-- OutgoingTransaction : extends via allOf
    TransactionOneOf o-- IncomingTransaction : discriminates
    TransactionOneOf o-- OutgoingTransaction : discriminates
    
    note for TransactionOneOf "API endpoints now reference TransactionOneOf instead of Transaction for proper polymorphic type handling"
    note for IncomingTransaction "Type field added with INCOMING enum for discrimination"
    note for OutgoingTransaction "Type field added with OUTGOING enum for discrimination"

Loading

_{Last reviewed commit: 36ee105}