Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThis PR syncs auto-generated account schemas from VASP adapter field definitions in sparkcore, adding support for 8 new currencies: BDT (Bangladeshi Taka), COP (Colombian Peso), EGP (Egyptian Pound), GHS (Ghanaian Cedi), GTQ (Guatemalan Quetzal), HTG (Haitian Gourde), JMD (Jamaican Dollar), and PKR (Pakistani Rupee). Each currency gets a consistent set of schemas: Confidence Score: 4/5Safe to merge after removing the erroneous LIGHTNING_ACCOUNT discriminator mapping; all other schema additions are consistent and well-structured. The 34 new currency schema files are well-formed and follow the existing patterns exactly. The only concrete issue is the incorrect LIGHTNING_ACCOUNT discriminator key in ExternalAccountInfoOneOf.yaml — it routes to a schema whose enum only accepts LIGHTNING, creating an unresolvable validation dead-end for that key. This is a targeted, one-line fix. The IBAN example concern is P2/style only. openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml — needs the erroneous LIGHTNING_ACCOUNT discriminator mapping removed.
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml | Adds 8 new currency entries to the oneOf list and discriminator mapping, but also incorrectly adds a duplicate LIGHTNING_ACCOUNT discriminator key that conflicts with the existing LIGHTNING mapping for the same schema. |
| openapi/components/schemas/common/PaymentInstructions.yaml | Adds 8 new currency entries (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR) to both the oneOf list and the discriminator mapping; no issues found. |
| openapi/components/schemas/common/UsdBeneficiary.yaml | Removes birthDate and nationality from the required fields list, making them optional — a backward-compatible relaxation of the schema. |
| openapi/components/schemas/common/UsdAccountInfo.yaml | Adds BANK_TRANSFER as a valid enum value for paymentRails, extending USD account support; additive change with no issues. |
| openapi/components/schemas/common/EgpAccountInfo.yaml | New EGP account schema with IBAN and SWIFT support; the IBAN example uses a German IBAN (DE...) which is misleading for an Egyptian currency schema. |
| openapi/components/schemas/common/PkrAccountInfo.yaml | New PKR account schema with IBAN support; the IBAN example uses a German IBAN (DE...) rather than a PKR-appropriate example. |
| openapi/components/schemas/common/BdtAccountInfo.yaml | New BDT account schema with BANK_TRANSFER and MOBILE_MONEY rails, branch code, SWIFT, and phone number; looks correct. |
| openapi/components/schemas/common/HtgAccountInfo.yaml | New HTG account schema with only MOBILE_MONEY rail and phone number (no bank account fields), consistent with mobile money-only market. |
| openapi/components/schemas/external_accounts/BdtExternalAccountInfo.yaml | New BDT external account composing BaseExternalAccountInfo + BdtAccountInfo with a required beneficiary (INDIVIDUAL/BUSINESS); pattern is consistent with all other currency external account schemas. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
EAOneOf["ExternalAccountInfoOneOf\n(oneOf discriminator)"] --> BDT["BdtExternalAccountInfo\n(BDT_ACCOUNT)"]
EAOneOf --> COP["CopExternalAccountInfo\n(COP_ACCOUNT)"]
EAOneOf --> EGP["EgpExternalAccountInfo\n(EGP_ACCOUNT)"]
EAOneOf --> GHS["GhsExternalAccountInfo\n(GHS_ACCOUNT)"]
EAOneOf --> GTQ["GtqExternalAccountInfo\n(GTQ_ACCOUNT)"]
EAOneOf --> HTG["HtgExternalAccountInfo\n(HTG_ACCOUNT)"]
EAOneOf --> JMD["JmdExternalAccountInfo\n(JMD_ACCOUNT)"]
EAOneOf --> PKR["PkrExternalAccountInfo\n(PKR_ACCOUNT)"]
BDT --> BdtAI["BdtAccountInfo\n(accountNumber, branchCode,\nswiftCode, phoneNumber)"]
BDT --> BdtB["BdtBeneficiary\nor BusinessBeneficiary"]
EAOneOf -. "LIGHTNING_ACCOUNT key\nshould not exist" .-> Lightning["LightningExternalAccountInfo\naccountType enum = LIGHTNING"]
PI["PaymentInstructions\n(oneOf discriminator)"] --> PBDT["PaymentBdtAccountInfo"]
PI --> PCOP["PaymentCopAccountInfo"]
PI --> PEGP["PaymentEgpAccountInfo"]
PI --> PGHS["PaymentGhsAccountInfo"]
PI --> PGTQ["PaymentGtqAccountInfo"]
PI --> PHTG["PaymentHtgAccountInfo"]
PI --> PJMD["PaymentJmdAccountInfo"]
PI --> PPKR["PaymentPkrAccountInfo"]
PBDT --> Base["BasePaymentAccountInfo\n(reference)"]
PBDT --> BdtAI
Comments Outside Diff (1)
-
openapi/components/schemas/common/EgpAccountInfo.yaml, line 203 (link)Misleading IBAN example for non-European currency
The
ibanfield usesDE89370400440532013000(a German IBAN) as the example value. Egyptian IBANs begin withEGand are 27 characters long, while German IBANs are 22 characters. Using a German IBAN as the example may mislead API consumers integrating with Egyptian banking systems.The same issue exists in
PkrAccountInfo.yaml— the IBAN example is also a German IBAN (DE89370400440532013000) even though Pakistani IBANs start withPKand are 24 characters long.Consider using country-appropriate example values:
- EGP:
EG380019000500000000263180002(Egyptian IBAN format) - PKR:
PK36SCBL0000001123456702(Pakistani IBAN format)
Prompt To Fix With AI
This is a comment left during a code review. Path: openapi/components/schemas/common/EgpAccountInfo.yaml Line: 203 Comment: **Misleading IBAN example for non-European currency** The `iban` field uses `DE89370400440532013000` (a German IBAN) as the example value. Egyptian IBANs begin with `EG` and are 27 characters long, while German IBANs are 22 characters. Using a German IBAN as the example may mislead API consumers integrating with Egyptian banking systems. The same issue exists in `PkrAccountInfo.yaml` — the IBAN example is also a German IBAN (`DE89370400440532013000`) even though Pakistani IBANs start with `PK` and are 24 characters long. Consider using country-appropriate example values: - EGP: `EG380019000500000000263180002` (Egyptian IBAN format) - PKR: `PK36SCBL0000001123456702` (Pakistani IBAN format) How can I resolve this? If you propose a fix, please make it concise.
- EGP:
Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 88
Comment:
**Incorrect `LIGHTNING_ACCOUNT` discriminator key for Lightning schema**
This PR adds `LIGHTNING_ACCOUNT: ./LightningExternalAccountInfo.yaml` to the discriminator mapping, but that key doesn't match the actual `accountType` enum value in `LightningInfo.yaml`, which is `LIGHTNING`. The correct discriminator entry (`LIGHTNING: ./LightningExternalAccountInfo.yaml`) is already present at line 72.
Having both `LIGHTNING` and `LIGHTNING_ACCOUNT` pointing to the same file means that a payload arriving with `accountType: LIGHTNING_ACCOUNT` will be routed to `LightningExternalAccountInfo.yaml` by the discriminator, but then fail schema validation immediately because the Lightning schema only permits `accountType: LIGHTNING` (enum constraint). This creates a confusing, unresolvable validation failure for consumers using that discriminator key.
The `LIGHTNING_ACCOUNT` entry should be removed from the mapping. It appears to have been accidentally included as part of the batch addition for the new currency schemas (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR).
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: openapi/components/schemas/common/EgpAccountInfo.yaml
Line: 203
Comment:
**Misleading IBAN example for non-European currency**
The `iban` field uses `DE89370400440532013000` (a German IBAN) as the example value. Egyptian IBANs begin with `EG` and are 27 characters long, while German IBANs are 22 characters. Using a German IBAN as the example may mislead API consumers integrating with Egyptian banking systems.
The same issue exists in `PkrAccountInfo.yaml` — the IBAN example is also a German IBAN (`DE89370400440532013000`) even though Pakistani IBANs start with `PK` and are 24 characters long.
Consider using country-appropriate example values:
- EGP: `EG380019000500000000263180002` (Egyptian IBAN format)
- PKR: `PK36SCBL0000001123456702` (Pakistani IBAN format)
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "chore: Sync account schemas" | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| GTQ_ACCOUNT: ./GtqExternalAccountInfo.yaml | ||
| HTG_ACCOUNT: ./HtgExternalAccountInfo.yaml | ||
| JMD_ACCOUNT: ./JmdExternalAccountInfo.yaml | ||
| LIGHTNING_ACCOUNT: ./LightningExternalAccountInfo.yaml |
There was a problem hiding this comment.
LIGHTNING_ACCOUNT discriminator key for Lightning schema
This PR adds LIGHTNING_ACCOUNT: ./LightningExternalAccountInfo.yaml to the discriminator mapping, but that key doesn't match the actual accountType enum value in LightningInfo.yaml, which is LIGHTNING. The correct discriminator entry (LIGHTNING: ./LightningExternalAccountInfo.yaml) is already present at line 72.
Having both LIGHTNING and LIGHTNING_ACCOUNT pointing to the same file means that a payload arriving with accountType: LIGHTNING_ACCOUNT will be routed to LightningExternalAccountInfo.yaml by the discriminator, but then fail schema validation immediately because the Lightning schema only permits accountType: LIGHTNING (enum constraint). This creates a confusing, unresolvable validation failure for consumers using that discriminator key.
The LIGHTNING_ACCOUNT entry should be removed from the mapping. It appears to have been accidentally included as part of the batch addition for the new currency schemas (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR).
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 88
Comment:
**Incorrect `LIGHTNING_ACCOUNT` discriminator key for Lightning schema**
This PR adds `LIGHTNING_ACCOUNT: ./LightningExternalAccountInfo.yaml` to the discriminator mapping, but that key doesn't match the actual `accountType` enum value in `LightningInfo.yaml`, which is `LIGHTNING`. The correct discriminator entry (`LIGHTNING: ./LightningExternalAccountInfo.yaml`) is already present at line 72.
Having both `LIGHTNING` and `LIGHTNING_ACCOUNT` pointing to the same file means that a payload arriving with `accountType: LIGHTNING_ACCOUNT` will be routed to `LightningExternalAccountInfo.yaml` by the discriminator, but then fail schema validation immediately because the Lightning schema only permits `accountType: LIGHTNING` (enum constraint). This creates a confusing, unresolvable validation failure for consumers using that discriminator key.
The `LIGHTNING_ACCOUNT` entry should be removed from the mapping. It appears to have been accidentally included as part of the batch addition for the new currency schemas (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR).
How can I resolve this? If you propose a fix, please make it concise.
Auto-synced account schemas.
These schemas are generated from VASP adapter field definitions in sparkcore.
Synced schemas:
common/— per-currency account info, beneficiary, and payment account schemascommon/PaymentInstructions.yaml— payment instructions oneOf (new currencies added)external_accounts/— per-currency external account schemas (reference common/)Please review the changes before merging.