fix: send articles_of_association as an object, not a bare string - #650
Conversation
…string OnboardSubEntityDocuments.articlesOfAssociation was typed as the enum ArticlesOfAssociationType, and no ArticlesOfAssociation class existed. The API requires an object with type and front, so the SDK serialized "articles_of_association": "articles_of_association" and the request was rejected. That document is required on the company full onboarding variants, so it could not be sent from Java at all. Found while verifying a report about the bank_verification document type, which Java already models correctly. Its siblings BankVerification and ShareholderStructure were objects all along; only this one was wrong. The field type changes, so this is source-breaking for anyone assigning the enum directly. They could not have been sending a valid request, since the old shape was rejected by the API, so nothing that worked stops working. Breaking because the API demands it, not by our choice: a minor, per the release rules, and called out in the release notes. One test asserts the old string shape is gone, not just that the new one is present. 2014 tests, 1 failure unrelated to this change: RefundPaymentsTestIT shouldRefundTokenPaymentSync fails with no_capture_balance_available_to_refund, a sandbox balance condition in payments. Refs INT-1691.
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 3 wall-e 2026.06.19-02 · policy |
🔬 Debug — why this classification?Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
🟢 Advisory review: Looks good to meThis PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on. Fixes What I checked
This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02 |
|
There was a problem hiding this comment.
✅ Auto-approved — this PR meets all Low-risk criteria.
All checks passed, no unresolved comments, and the change classification is:
no_low_class_matchedprod_source_modified2.2.6_logical_extension:This fix corrects a field type in an existing model class from a bare enum to a proper object, reusing existing abstractions (ArticlesOfAssociationType, OnboardSubEntityDocuments) without adding new endpoints, persisted data, auth changes, or external integrations.
wall-e 2026.06.19-02 · policy 376219bc71e6…



What
articles_of_associationwas being serialized as a bare string instead of an object, so the API rejected it. That document is required on the company full onboarding variants, which means it could not be sent from Java at all.The bug
OnboardSubEntityDocuments.articlesOfAssociationwas typed as the enumArticlesOfAssociationType, and noArticlesOfAssociationclass existed. The result:{"articles_of_association": "articles_of_association"}The spec requires an object:
{"articles_of_association": {"type": "articles_of_association", "front": "file_..."}}Its siblings
BankVerificationandShareholderStructurewere modelled correctly as objects all along. Only this one was wrong.Found while verifying an internal report about the
bank_verificationdocument type, which Java already models correctly.Breaking, and why it is still a minor
The field type changes, so this is source-breaking for anyone assigning the enum directly to it. Nobody could have been sending a valid request that way, since the API rejected the old shape, so nothing that worked stops working.
Breaking because the API demands it, not by our choice, so a minor per the release rules. Worth calling out in the release notes.
Tests
Four tests, including one that asserts the old string shape is gone, not merely that the new one is present.
Suite: 2014 tests, 1 failure unrelated to this change —
RefundPaymentsTestIT.shouldRefundTokenPaymentSyncfails withno_capture_balance_available_to_refund, a sandbox balance condition in payments.Refs INT-1691.