Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThis auto-synced PR expands the Grid API schema coverage for 8 new fiat currencies (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR) by adding account info, beneficiary, payment account info, and external account info YAML schemas, and wiring them into the Confidence Score: 4/5Safe to merge after confirming the LIGHTNING_ACCOUNT alias addition is intentional; all other changes are well-structured schema additions and backwards-compatible relaxations. The bulk of the PR is a clean, consistent expansion of 8 new currency schemas that follow established patterns exactly. The only meaningful question mark is the unexplained LIGHTNING_ACCOUNT discriminator alias in ExternalAccountInfoOneOf.yaml — if confirmed intentional, the PR is ready to merge. The IBAN example issues are cosmetic P2s. The registrationNumber removal is a deliberate upstream sync. openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml — verify the LIGHTNING_ACCOUNT mapping addition is intentional
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml | Adds 8 new currency account types to the oneOf list and discriminator mapping; also adds a LIGHTNING_ACCOUNT alias mapping that has no matching oneOf entry and no clear explanation — needs confirmation this is intentional. |
| openapi/components/schemas/common/PaymentInstructions.yaml | Cleanly adds 8 new payment account types (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR) to both the oneOf list and discriminator mapping — consistent with existing pattern. |
| openapi/components/schemas/common/EgpAccountInfo.yaml | New EGP account schema with correct validation patterns; minor issue: IBAN example uses a German (DE) IBAN instead of an Egyptian (EG) one. |
| openapi/components/schemas/common/PkrAccountInfo.yaml | New PKR account schema with correct validation patterns; minor issue: IBAN example uses a German (DE) IBAN instead of a Pakistani (PK) one. |
| openapi/components/schemas/common/UsdBeneficiary.yaml | Removes birthDate and nationality from required fields (now optional) and removes the optional registrationNumber property — both are backwards-compatible relaxations. |
| openapi/components/schemas/common/UsdAccountInfo.yaml | Adds BANK_TRANSFER as a new supported payment rail enum value for USD accounts — backwards-compatible addition. |
| openapi/components/schemas/common/BdtAccountInfo.yaml | New BDT account schema with BANK_TRANSFER/MOBILE_MONEY rails, accountNumber, branchCode, optional swiftCode, and required phoneNumber — well-structured with appropriate constraints. |
| openapi/components/schemas/external_accounts/BdtExternalAccountInfo.yaml | New BDT external account schema composing BaseExternalAccountInfo + BdtAccountInfo with an INDIVIDUAL/BUSINESS beneficiary discriminator — follows established pattern correctly. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[New Currency<br/>AccountInfo YAML] --> B[PaymentXxxAccountInfo<br/>allOf: Base + AccountInfo + reference]
A --> C[XxxExternalAccountInfo<br/>allOf: Base + AccountInfo + beneficiary oneOf]
B --> D[PaymentInstructions.yaml<br/>oneOf + discriminator mapping]
C --> E[ExternalAccountInfoOneOf.yaml<br/>oneOf + discriminator mapping]
F[New Beneficiary YAML<br/>BDT/COP/EGP/GHS/GTQ/HTG/JMD/PKR] --> C
G[Existing Beneficiaries<br/>~20 currencies] -->|removed registrationNumber| H[Updated Beneficiary Schemas]
I[UsdBeneficiary] -->|birthDate + nationality no longer required| H
J[UsdAccountInfo] -->|added BANK_TRANSFER rail| K[Updated AccountInfo]
E -->|Warning: Unexpected addition| L[LIGHTNING_ACCOUNT alias<br/>to LightningExternalAccountInfo]
Comments Outside Diff (1)
-
openapi/components/schemas/common/EgpAccountInfo.yaml, line 253 (link)German IBAN example used for an Egyptian account
The
ibanfield usesDE89370400440532013000as an example value, which is a well-known German IBAN. For an Egyptian Pound (EGP) account, the example should use an Egyptian IBAN (starts withEG), e.g.EG380019000500000000263180002.The same issue exists in
PkrAccountInfo.yamlwhereDE89370400440532013000is used as an example for a Pakistani account — it should start withPK, e.g.PK36SCBL0000001123456702.Prompt To Fix With AI
This is a comment left during a code review. Path: openapi/components/schemas/common/EgpAccountInfo.yaml Line: 253 Comment: **German IBAN example used for an Egyptian account** The `iban` field uses `DE89370400440532013000` as an example value, which is a well-known German IBAN. For an Egyptian Pound (`EGP`) account, the example should use an Egyptian IBAN (starts with `EG`), e.g. `EG380019000500000000263180002`. The same issue exists in `PkrAccountInfo.yaml` where `DE89370400440532013000` is used as an example for a Pakistani account — it should start with `PK`, e.g. `PK36SCBL0000001123456702`. How can I resolve this? If you propose a fix, please make it concise.
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:
**Unexpected `LIGHTNING_ACCOUNT` mapping added**
A new discriminator mapping entry `LIGHTNING_ACCOUNT: ./LightningExternalAccountInfo.yaml` was added alongside the new currency entries, but it doesn't follow the same pattern as every other new entry in this PR:
- Every new currency (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR) gets both a new `$ref` in the `oneOf` list **and** a new discriminator `mapping` entry.
- `LIGHTNING_ACCOUNT` only gets a mapping entry — there is no new `$ref` added to the `oneOf` list.
`LIGHTNING` is already mapped at line 72 (`LIGHTNING: ./LightningExternalAccountInfo.yaml`). This new entry effectively creates an alias so that `accountType: "LIGHTNING_ACCOUNT"` resolves to the same schema as `accountType: "LIGHTNING"`.
Is this intentional (e.g., to support a renamed discriminator value for backward compatibility), or was it accidentally included alongside the new currencies?
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: 253
Comment:
**German IBAN example used for an Egyptian account**
The `iban` field uses `DE89370400440532013000` as an example value, which is a well-known German IBAN. For an Egyptian Pound (`EGP`) account, the example should use an Egyptian IBAN (starts with `EG`), e.g. `EG380019000500000000263180002`.
```suggestion
example: EG380019000500000000263180002
```
The same issue exists in `PkrAccountInfo.yaml` where `DE89370400440532013000` is used as an example for a Pakistani account — it should start with `PK`, e.g. `PK36SCBL0000001123456702`.
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/PkrAccountInfo.yaml
Line: 37
Comment:
**German IBAN example used for a Pakistani account**
The `iban` field uses `DE89370400440532013000` as an example, which is a German IBAN. A Pakistani IBAN starts with `PK`, e.g. `PK36SCBL0000001123456702`.
```suggestion
example: PK36SCBL0000001123456702
```
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 mapping added
A new discriminator mapping entry LIGHTNING_ACCOUNT: ./LightningExternalAccountInfo.yaml was added alongside the new currency entries, but it doesn't follow the same pattern as every other new entry in this PR:
- Every new currency (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR) gets both a new
$refin theoneOflist and a new discriminatormappingentry. LIGHTNING_ACCOUNTonly gets a mapping entry — there is no new$refadded to theoneOflist.
LIGHTNING is already mapped at line 72 (LIGHTNING: ./LightningExternalAccountInfo.yaml). This new entry effectively creates an alias so that accountType: "LIGHTNING_ACCOUNT" resolves to the same schema as accountType: "LIGHTNING".
Is this intentional (e.g., to support a renamed discriminator value for backward compatibility), or was it accidentally included alongside the new currencies?
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:
**Unexpected `LIGHTNING_ACCOUNT` mapping added**
A new discriminator mapping entry `LIGHTNING_ACCOUNT: ./LightningExternalAccountInfo.yaml` was added alongside the new currency entries, but it doesn't follow the same pattern as every other new entry in this PR:
- Every new currency (BDT, COP, EGP, GHS, GTQ, HTG, JMD, PKR) gets both a new `$ref` in the `oneOf` list **and** a new discriminator `mapping` entry.
- `LIGHTNING_ACCOUNT` only gets a mapping entry — there is no new `$ref` added to the `oneOf` list.
`LIGHTNING` is already mapped at line 72 (`LIGHTNING: ./LightningExternalAccountInfo.yaml`). This new entry effectively creates an alias so that `accountType: "LIGHTNING_ACCOUNT"` resolves to the same schema as `accountType: "LIGHTNING"`.
Is this intentional (e.g., to support a renamed discriminator value for backward compatibility), or was it accidentally included alongside the new currencies?
How can I resolve this? If you propose a fix, please make it concise.| example: '+1234567890' | ||
| minLength: 7 | ||
| maxLength: 15 | ||
| pattern: ^\+[0-9]{6,14}$ |
There was a problem hiding this comment.
The iban field uses DE89370400440532013000 as an example, which is a German IBAN. A Pakistani IBAN starts with PK, e.g. PK36SCBL0000001123456702.
| pattern: ^\+[0-9]{6,14}$ | |
| example: PK36SCBL0000001123456702 |
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/PkrAccountInfo.yaml
Line: 37
Comment:
**German IBAN example used for a Pakistani account**
The `iban` field uses `DE89370400440532013000` as an example, which is a German IBAN. A Pakistani IBAN starts with `PK`, e.g. `PK36SCBL0000001123456702`.
```suggestion
example: PK36SCBL0000001123456702
```
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.