chore: Update external account schemas from webdev#143
chore: Update external account schemas from webdev#143lightspark-copybara[bot] wants to merge 1 commit intomainfrom
Conversation
Greptile OverviewGreptile SummaryAuto-synced two new external account schemas from sparkcore VASP adapter field definitions: Key Issues:
Questions:
Confidence Score: 2/5
|
| 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
| 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 |
There was a problem hiding this comment.
This schema introduces INR_UPI_ACCOUNT as a new account type but it's not registered in:
ExternalAccountInfoOneOf.yaml(discriminator oneOf list and mapping)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.| fullName: | ||
| type: string | ||
| description: Full name of the beneficiary | ||
| example: John Michael Doe |
There was a problem hiding this 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.
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.| 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 |
There was a problem hiding this comment.
This schema introduces MXN_SPEI_ACCOUNT as a new account type but it's not registered in:
ExternalAccountInfoOneOf.yaml(discriminator oneOf list and mapping)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.| clabe: | ||
| type: string | ||
| description: Mexican CLABE interbank account number (18 digits) | ||
| example: 012180001234567890 |
There was a problem hiding this 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.
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.| name: | ||
| type: string | ||
| description: Full name of the payee | ||
| example: Jane Smith |
There was a problem hiding this 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.
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.
Auto-synced external account schemas from webdev.
These schemas are generated from VASP adapter field definitions in sparkcore.
Please review the changes before merging.