chore: Update external account schemas from webdev#151
chore: Update external account schemas from webdev#151lightspark-copybara[bot] wants to merge 1 commit intomainfrom
Conversation
Greptile OverviewGreptile SummaryAdded two new external account types for cross-border payment corridors: MXN SPEI (Mexican banking) and INR UPI (Indian payments). The schemas define required fields for USD → MXN and USD → INR payment flows. Key Issues Found:
Impact: Confidence Score: 2/5
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml | Added two new account types (MXN_SPEI_ACCOUNT and INR_UPI_ACCOUNT) to oneOf and discriminator mapping, but titles don't follow existing naming pattern |
| openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml | New INR UPI account schema with inline beneficiary definition that doesn't match existing patterns - should use BeneficiaryOneOf reference |
| openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml | New MXN SPEI account schema with inline beneficiary definition that doesn't match existing patterns - should use BeneficiaryOneOf reference |
Sequence Diagram
sequenceDiagram
participant WebDev as Webdev (VASP Adapter)
participant CopyBot as lightspark-copybara[bot]
participant GridAPI as Grid API (OpenAPI Spec)
participant Consumer as API Consumers
WebDev->>WebDev: Define MXN SPEI & INR UPI<br/>account fields in sparkcore
WebDev->>WebDev: Generate schemas from<br/>VASP adapter definitions
WebDev->>CopyBot: Auto-sync trigger
CopyBot->>GridAPI: Create PR with new schemas<br/>(MxnSpeiAccountInfo, InrUpiAccountInfo)
CopyBot->>GridAPI: Update ExternalAccountInfoOneOf<br/>with new account types
Note over GridAPI: Review identifies schema<br/>structure inconsistencies
GridAPI-->>Consumer: Once merged, new account<br/>types available in API
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| - title: MxnSpeiAccountInfo | ||
| $ref: ./MxnSpeiAccountInfo.yaml | ||
| - title: InrUpiAccountInfo | ||
| $ref: ./InrUpiAccountInfo.yaml |
There was a problem hiding this comment.
Title naming inconsistent with existing patterns. Other entries use descriptive titles like "US Account", "CLABE Account", "UPI Account" but these use schema names "MxnSpeiAccountInfo" and "InrUpiAccountInfo"
| - title: MxnSpeiAccountInfo | |
| $ref: ./MxnSpeiAccountInfo.yaml | |
| - title: InrUpiAccountInfo | |
| $ref: ./InrUpiAccountInfo.yaml | |
| - title: MXN SPEI Account | |
| $ref: ./MxnSpeiAccountInfo.yaml | |
| - title: INR UPI Account | |
| $ref: ./InrUpiAccountInfo.yaml |
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 34:37
Comment:
Title naming inconsistent with existing patterns. Other entries use descriptive titles like "US Account", "CLABE Account", "UPI Account" but these use schema names "MxnSpeiAccountInfo" and "InrUpiAccountInfo"
```suggestion
- title: MXN SPEI Account
$ref: ./MxnSpeiAccountInfo.yaml
- title: INR UPI Account
$ref: ./InrUpiAccountInfo.yaml
```
<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>
How can I resolve this? If you propose a fix, please make it concise.| beneficiary: | ||
| type: object | ||
| required: | ||
| - fullName | ||
| properties: | ||
| fullName: | ||
| type: string | ||
| description: Individual's full name | ||
| example: John Michael Doe |
There was a problem hiding this comment.
Beneficiary structure doesn't match existing external account patterns. Other account types (e.g., UpiAccountExternalAccountInfo.yaml:9, ClabeAccountExternalAccountInfo.yaml:9, NgnAccountExternalAccountInfo.yaml:27) use $ref: ./BeneficiaryOneOf.yaml which supports both individual and business beneficiaries with proper validation. This inline definition only accepts fullName without beneficiaryType, birthDate, or nationality fields required by IndividualBeneficiary.yaml:4-8
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml
Line: 18:26
Comment:
Beneficiary structure doesn't match existing external account patterns. Other account types (e.g., `UpiAccountExternalAccountInfo.yaml:9`, `ClabeAccountExternalAccountInfo.yaml:9`, `NgnAccountExternalAccountInfo.yaml:27`) use `$ref: ./BeneficiaryOneOf.yaml` which supports both individual and business beneficiaries with proper validation. This inline definition only accepts `fullName` without `beneficiaryType`, `birthDate`, or `nationality` fields required by `IndividualBeneficiary.yaml:4-8`
How can I resolve this? If you propose a fix, please make it concise.| beneficiary: | ||
| type: object | ||
| required: | ||
| - fullName | ||
| properties: | ||
| fullName: | ||
| type: string | ||
| description: Individual's full name | ||
| example: John Michael Doe |
There was a problem hiding this comment.
Beneficiary structure doesn't match existing external account patterns. Other account types (e.g., UpiAccountExternalAccountInfo.yaml:9, ClabeAccountExternalAccountInfo.yaml:9, NgnAccountExternalAccountInfo.yaml:27) use $ref: ./BeneficiaryOneOf.yaml which supports both individual and business beneficiaries with proper validation. This inline definition only accepts fullName without beneficiaryType, birthDate, or nationality fields required by IndividualBeneficiary.yaml:4-8
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 21:29
Comment:
Beneficiary structure doesn't match existing external account patterns. Other account types (e.g., `UpiAccountExternalAccountInfo.yaml:9`, `ClabeAccountExternalAccountInfo.yaml:9`, `NgnAccountExternalAccountInfo.yaml:27`) use `$ref: ./BeneficiaryOneOf.yaml` which supports both individual and business beneficiaries with proper validation. This inline definition only accepts `fullName` without `beneficiaryType`, `birthDate`, or `nationality` fields required by `IndividualBeneficiary.yaml:4-8`
How can I resolve this? If you propose a fix, please make it concise.| type: object | ||
| title: InrUpiAccountInfo | ||
| description: Required fields for USD -> INR corridor via Upi | ||
| required: | ||
| - accountType | ||
| - beneficiary | ||
| - vpa |
There was a problem hiding this comment.
Schema structure inconsistent with existing patterns. Other external account schemas (e.g., UpiAccountExternalAccountInfo.yaml:1-9, ClabeAccountExternalAccountInfo.yaml:1-9) use allOf composition to extend BaseExternalAccountInfo.yaml and reference common account info schemas. This standalone schema doesn't inherit base properties or use the established composition pattern
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml
Line: 1:7
Comment:
Schema structure inconsistent with existing patterns. Other external account schemas (e.g., `UpiAccountExternalAccountInfo.yaml:1-9`, `ClabeAccountExternalAccountInfo.yaml:1-9`) use `allOf` composition to extend `BaseExternalAccountInfo.yaml` and reference common account info schemas. This standalone schema doesn't inherit base properties or use the established composition pattern
How can I resolve this? If you propose a fix, please make it concise.| type: object | ||
| title: MxnSpeiAccountInfo | ||
| description: Required fields for USD -> MXN corridor via Spei | ||
| required: | ||
| - accountType | ||
| - beneficiary | ||
| - clabeNumber |
There was a problem hiding this comment.
Schema structure inconsistent with existing patterns. Other external account schemas (e.g., UpiAccountExternalAccountInfo.yaml:1-9, ClabeAccountExternalAccountInfo.yaml:1-9) use allOf composition to extend BaseExternalAccountInfo.yaml and reference common account info schemas. This standalone schema doesn't inherit base properties or use the established composition pattern
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 1:7
Comment:
Schema structure inconsistent with existing patterns. Other external account schemas (e.g., `UpiAccountExternalAccountInfo.yaml:1-9`, `ClabeAccountExternalAccountInfo.yaml:1-9`) use `allOf` composition to extend `BaseExternalAccountInfo.yaml` and reference common account info schemas. This standalone schema doesn't inherit base properties or use the established composition pattern
How can I resolve this? If you propose a fix, please make it concise.
Auto-synced external account schemas from webdev.
These schemas are generated from VASP adapter field definitions in sparkcore.
Please review the changes before merging.