Skip to content

chore: Update external account schemas from webdev#143

Open
lightspark-copybara[bot] wants to merge 1 commit intomainfrom
auto/sync-external-accounts-20260204-044146
Open

chore: Update external account schemas from webdev#143
lightspark-copybara[bot] wants to merge 1 commit intomainfrom
auto/sync-external-accounts-20260204-044146

Conversation

@lightspark-copybara
Copy link

Auto-synced external account schemas from webdev.

These schemas are generated from VASP adapter field definitions in sparkcore.

Please review the changes before merging.

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Feb 4, 2026

Greptile Overview

Greptile Summary

Auto-synced two new external account schemas from sparkcore VASP adapter field definitions: InrUpiAccountInfo.yaml for INR UPI accounts and MxnSpeiAccountInfo.yaml for Mexican SPEI accounts.

Key Issues:

  • Both schemas introduce new account types (INR_UPI_ACCOUNT, MXN_SPEI_ACCOUNT) but are not registered in ExternalAccountInfoOneOf.yaml or ExternalAccountType.yaml, making them unusable in the API
  • Field naming inconsistencies: these schemas use standalone fullName/name fields instead of the established beneficiary object pattern used in existing account types
  • MxnSpeiAccountInfo uses clabe field without validation constraints (missing minLength, maxLength, pattern), while existing ClabeAccountInfo.yaml has proper 18-digit validation
  • Schema structure differs from existing patterns - standalone objects rather than allOf compositions with BaseExternalAccountInfo

Questions:

  • Are these schemas intended for internal VASP operations only, or should they be integrated into the public API?
  • Should these follow the existing architecture patterns, or is this a new parallel structure?

Confidence Score: 2/5

  • This PR introduces schemas that are not integrated into the API and have inconsistencies with existing patterns
  • Score reflects critical integration gaps - the new account types are not registered in discriminator mappings or enum definitions, making them non-functional. Additionally, field naming and validation patterns deviate from established conventions without clear justification.
  • Both InrUpiAccountInfo.yaml and MxnSpeiAccountInfo.yaml require attention for integration and consistency issues

Important Files Changed

Filename Overview
openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml New INR UPI account schema added, but not integrated into ExternalAccountInfoOneOf or ExternalAccountType enum
openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml New MXN SPEI account schema added with inconsistent field names compared to existing patterns

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant Sparkcore as Sparkcore (VASP Adapter)
    participant AutoSync as Auto-sync Process
    participant GridAPI as Grid API Schemas
    participant OpenAPI as OpenAPI Specification
    
    Note over Sparkcore: VASP adapter field<br/>definitions updated
    Sparkcore->>AutoSync: Trigger schema sync
    AutoSync->>GridAPI: Generate InrUpiAccountInfo.yaml
    AutoSync->>GridAPI: Generate MxnSpeiAccountInfo.yaml
    Note over GridAPI: New schemas added to<br/>external_accounts/
    GridAPI->>OpenAPI: Schemas available for use
    Note over OpenAPI: ⚠️ Not registered in<br/>ExternalAccountInfoOneOf<br/>or ExternalAccountType
    Dev->>GridAPI: Review PR #143
    Note over Dev: Verify integration<br/>requirements
Loading

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 files reviewed, 5 comments

Edit Code Review Agent Settings | Greptile

Comment on lines +1 to +21
type: object
title: InrUpiAccountInfo
description: Required fields for USD -> INR corridor via Upi
required:
- accountType
- fullName
- vpa
properties:
accountType:
type: string
enum:
- INR_UPI_ACCOUNT
example: INR_UPI_ACCOUNT
fullName:
type: string
description: Full name of the beneficiary
example: John Michael Doe
vpa:
type: string
description: Virtual Payment Address (UPI)
example: john@upi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This schema introduces INR_UPI_ACCOUNT as a new account type but it's not registered in:

  1. ExternalAccountInfoOneOf.yaml (discriminator oneOf list and mapping)
  2. ExternalAccountType.yaml (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml
Line: 1:21

Comment:
This schema introduces `INR_UPI_ACCOUNT` as a new account type but it's not registered in:
1. `ExternalAccountInfoOneOf.yaml` (discriminator oneOf list and mapping)
2. `ExternalAccountType.yaml` (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

How can I resolve this? If you propose a fix, please make it concise.

Comment on lines +14 to +17
fullName:
type: string
description: Full name of the beneficiary
example: John Michael Doe
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Field fullName is inconsistent with existing patterns. The existing UpiAccountExternalAccountInfo.yaml uses a beneficiary object with IndividualBeneficiary or BusinessBeneficiary types. This standalone fullName field doesn't align with the established beneficiary pattern used across other account types.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml
Line: 14:17

Comment:
Field `fullName` is inconsistent with existing patterns. The existing `UpiAccountExternalAccountInfo.yaml` uses a `beneficiary` object with `IndividualBeneficiary` or `BusinessBeneficiary` types. This standalone `fullName` field doesn't align with the established beneficiary pattern used across other account types.

How can I resolve this? If you propose a fix, please make it concise.

Comment on lines +1 to +21
type: object
title: MxnSpeiAccountInfo
description: Required fields for USD -> MXN corridor via Spei
required:
- accountType
- clabe
- name
properties:
accountType:
type: string
enum:
- MXN_SPEI_ACCOUNT
example: MXN_SPEI_ACCOUNT
clabe:
type: string
description: Mexican CLABE interbank account number (18 digits)
example: 012180001234567890
name:
type: string
description: Full name of the payee
example: Jane Smith
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This schema introduces MXN_SPEI_ACCOUNT as a new account type but it's not registered in:

  1. ExternalAccountInfoOneOf.yaml (discriminator oneOf list and mapping)
  2. ExternalAccountType.yaml (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 1:21

Comment:
This schema introduces `MXN_SPEI_ACCOUNT` as a new account type but it's not registered in:
1. `ExternalAccountInfoOneOf.yaml` (discriminator oneOf list and mapping)
2. `ExternalAccountType.yaml` (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

How can I resolve this? If you propose a fix, please make it concise.

Comment on lines +14 to +17
clabe:
type: string
description: Mexican CLABE interbank account number (18 digits)
example: 012180001234567890
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Field clabe differs from existing pattern in ClabeAccountInfo.yaml which uses clabeNumber with validation (18 digits, pattern ^[0-9]{18}$). This schema lacks the validation constraints present in the existing implementation.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 14:17

Comment:
Field `clabe` differs from existing pattern in `ClabeAccountInfo.yaml` which uses `clabeNumber` with validation (18 digits, pattern `^[0-9]{18}$`). This schema lacks the validation constraints present in the existing implementation.

How can I resolve this? If you propose a fix, please make it concise.

Comment on lines +18 to +21
name:
type: string
description: Full name of the payee
example: Jane Smith
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Field name is inconsistent with existing patterns. The existing ClabeAccountExternalAccountInfo.yaml uses a beneficiary object structure. This standalone name field doesn't align with the established beneficiary pattern used across other account types.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 18:21

Comment:
Field `name` is inconsistent with existing patterns. The existing `ClabeAccountExternalAccountInfo.yaml` uses a `beneficiary` object structure. This standalone `name` field doesn't align with the established beneficiary pattern used across other account types.

How can I resolve this? If you propose a fix, please make it concise.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants