Skip to content

fix(kyc-controller): Remove consent property from the GET /disclaimers return type - #10079

Merged
Akaryatrh merged 2 commits into
mainfrom
jl/kyc-controller-make-consented-optional
Sep 2, 2026
Merged

fix(kyc-controller): Remove consent property from the GET /disclaimers return type#10079
Akaryatrh merged 2 commits into
mainfrom
jl/kyc-controller-make-consented-optional

Conversation

@jiexi

@jiexi jiexi commented Sep 2, 2026

Copy link
Copy Markdown
Member

Explanation

Fixes incorrect typing causing validation to fail when fetching session disclaimers

References

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed
  • I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Note

Medium Risk
Breaking public types and response validation for disclaimer flows; incorrect assumptions about consented on the global catalog could break compile-time or runtime consumers until they adopt KycCatalogDocument.

Overview
Separates global disclaimer catalog documents from session-scoped consent documents so GET /disclaimers no longer implies per-document consented state.

Introduces KycCatalogDocument (key, version, title, url only) and types KycDisclaimersCatalog with KycCatalogDocument[]. KycConsentDocument is now KycCatalogDocument & { consented: boolean }, and KycSessionDisclaimers explicitly uses consent documents plus credentialReusabilityConsentGiven.

Runtime validation in KycService matches the API: GlobalDisclaimersResponseStruct validates catalog fields only; session responses still require consented on each document (new test when consented is omitted). Docs and tests are updated accordingly.

Breaking for TypeScript consumers that treated global catalog entries as KycConsentDocument with consented.

Reviewed by Cursor Bugbot for commit 33c8851. Bugbot is set up for automated code reviews on this repo. Configure here.

@jiexi
jiexi requested a review from a team as a code owner September 2, 2026 18:34
@jiexi
jiexi deployed to default-branch September 2, 2026 18:34 — with GitHub Actions Active
The generated action-types file copies JSDoc verbatim from the source, so
the hand-reflowed comment made `messenger-action-types:check` fail.

Co-authored-by: Cursor <cursoragent@cursor.com>

@Akaryatrh Akaryatrh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Akaryatrh
Akaryatrh added this pull request to the merge queue Sep 2, 2026
Merged via the queue into main with commit 78de2ac Sep 2, 2026
46 checks passed
@Akaryatrh
Akaryatrh deleted the jl/kyc-controller-make-consented-optional branch September 2, 2026 20:24
jiexi added a commit to MetaMask/metamask-mobile that referenced this pull request Sep 2, 2026
<!--
Please submit this PR as a draft initially.

Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.

In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
<!--
mms-check directive vocabulary — read by
.github/scripts/shared/pr-template-checks.ts
at module load to build the validation plan. Directives are invisible in
rendered
markdown and must NOT be removed or edited without updating the
validator registry.

  type=text           Section must contain non-placeholder prose.
  type=changelog      Section must have a valid CHANGELOG entry: line.
type=issue-link Section must have a Fixes:/Closes:/Refs: line with a
value.
type=manual-testing Section must have real testing steps or an explicit
N/A.
type=screenshot Section must have evidence (image/URL) or an explicit
N/A.
type=checklist Section must have all checkboxes consciously checked.
required=true|false Whether a missing/invalid section runs the validator
at all.
blocking=true|false Whether a failure of this check fails the CI
workflow.
Default: false — failures are shown as warnings in the sticky
                      comment but do not block the PR.

Sections without a directive are checked for structural presence only.
-->

## **Description**

Adopts the changes in MetaMask/core#10062

and the changes in MetaMask/core#10079 


## **Changelog**

<!-- mms-check: type=changelog required=true blocking=true -->

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry:

## **Related issues**

<!-- mms-check: type=issue-link required=true -->

Fixes:

## **Manual testing steps**

<!-- mms-check: type=manual-testing required=true -->

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- mms-check: type=screenshot required=true -->

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

<!-- mms-check: type=checklist required=true -->

<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.

Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->

- [ ] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I've included tests if applicable
- [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

#### Performance checks (if applicable)

- [ ] I've tested on Android
  - Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example

For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).

## **Pre-merge reviewer checklist**

<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.


<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **High Risk**
> Touches identity verification (Iron/UKYC/Sumsub), EIP-191 wallet
registration, autoramp creation against live dev proxies, and persistent
KYC state—mistakes could affect money onboarding or signing prompts.
> 
> **Overview**
> Adds **Brazil virtual bank account (VBA) demo flow** end-to-end:
navigation for mock KYC email/success and account status screens, **Iron
→ Sumsub** orchestration via new `ironKycFlow` helpers, and **Get Pix
Key** now initializes Iron KYC before advancing instead of only
navigating.
> 
> **Engine** registers **`KycService`**, **`KycController`** (with React
Native Sumsub launcher), and **`NeoBankService`**, clears KYC state on
wallet reset, and subscribes **`registerMoneyAccountOnKycCompletion`**
to `KycController:statusChanged` so completed KYC can auto **register
the Money Account wallet** and **create a BRL→mUSD/Monad autoramp**
(deduped with the manual pipeline on `MockKycSuccess`).
**`VirtualBankAccount`** refreshes autoramps and listens on a **neobank
WebSocket** while focused.
> 
> **Money tab** gains **`useNeobankSandboxDepositEvents`** (Iron
customer id resolution + dev WebSocket) to show a **deposit success
toast only**—no vault submit. **Dev tooling**: `vbaTrace` streams to the
ramps debug dashboard; neobank `fetch` is traced in `__DEV__`. Android
adds the **Sumsub Maven** repo; **idOS JWKS** URLs land in
`AppConstants`; **`addPrecreatedOrder`** passes required `chainId`.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
80b869c. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants