[ECUK In-App 3DS] Adds new error handling system to Multifactor Authentication by dariusz-biela · Pull Request #82297 · Expensify/App

dariusz-biela · 2026-02-12T18:12:28Z

Explanation of Change

This PR replaces the route-parameter-based MFA outcome system with a context-driven, component-based architecture.

What changed:

Routing simplification — Replaced the single parameterized route (/outcome/:outcomeType) with two static routes (/outcome/success, /outcome/failure). Outcome determination now happens entirely within OutcomePage by reading MFA context state, eliminating the need for outcome path generation (outcomePaths.ts, mapMultifactorAuthenticationOutcomes.ts — both deleted).
Client/server error split — Extended ErrorState with httpStatus and message fields propagated from the HTTP response. OutcomePage now distinguishes between client errors (4xx → defaultClientFailureScreen) and server errors (5xx or UNKNOWN_RESPONSE → defaultServerFailureScreen), showing appropriate UI for each.
Component-based screen resolution — Replaced OUTCOMES configuration objects with React elements stored directly in scenario config. Each scenario can override successScreen, defaultClientFailureScreen, defaultServerFailureScreen, and per-reason failureScreens. A createScreenWithDefaults factory enables layered composition — specialized screens extend base screens by overriding only the props that differ.
Shared base components — Extracted OutcomeScreenBase, FailureScreenBase, and SuccessScreenBase as reusable layout components. Default screens (DefaultClientFailureScreen, DefaultServerFailureScreen, DefaultSuccessScreen, etc.) are created via the factory and exported from DefaultUserInterface.
Scenario config stored in state — Full scenario config (including UI screens, modals, allowed methods) is resolved at INIT and stored in context state, replacing the previous pattern of storing only the scenario name and doing repeated lookups.
Error resilience — Added try/catch for unhandled errors in the MFA process flow, and AuthenticationMethodDescription component with a fallback for missing authType.

Fixed Issues

$ #80537
PROPOSAL:

Tests

Note: MFA is currently only accessible from the Troubleshoot pane.

Unsupported device error (Web):

Open the app on Web
Navigate to Settings > Troubleshoot
Tap "Test biometrics"
Verify the unsupported device failure screen is displayed (since Web does not support biometrics)

Success and failure screens (Mobile):

Open the app on a mobile device (iOS or Android)
Navigate to Settings > Troubleshoot
Tap "Test biometrics"
Complete the biometric authentication successfully
Verify the success screen is displayed with the correct authentication method description (e.g. "Face ID", "Fingerprint")
Go back and tap "Test biometrics" again
Cancel or fail the biometric authentication
Verify the appropriate failure screen is displayed

Server error (Web or Mobile):

Navigate to Settings > Troubleshoot
Enable the "Simulate failing network requests" toggle
Tap "Test biometrics"
Verify the server failure screen is displayed (with the Humpty Dumpty illustration)
Disable the "Simulate failing network requests" toggle

Verify that no errors appear in the JS console

Offline tests

N/A — MFA does not have offline-specific behavior; network failure is covered by the server error test above.

QA Steps

Same as Tests.

NOTE: This feature is behind a beta, so if it fails QA, it doesn't need a revert or a deploy blocker. Instead, please tag the PR reviewers in Slack and we'll decide how to move forward.

PR Author Checklist

Screenshots/Videos

Web: Unsupported device

Mobile: Server failure

Mobile: Client failure

Mobile: Sucess

…stead of route params Remove outcome path generation (outcomePaths.ts, mapMultifactorAuthenticationOutcomes.ts) and related types. OutcomePage now determines success/failure and specific error outcome entirely from MFA context state instead of route params. Split OUTCOME screen into OUTCOME_SUCCESS and OUTCOME_FAILURE as two separate routes pointing to the same component.

… name Eliminates redundant MULTIFACTOR_AUTHENTICATION_SCENARIO_CONFIG lookups by resolving the scenario config during INIT and storing it directly in state. Consumers now access scenario properties (OUTCOMES, MODALS, allowedAuthenticationMethods) directly from state.scenario.

…MFA outcomes

…teScreenWithDefaults factory

Use IllustrationName with lazy loading in base components, make subtitle optional in FailureScreenBase, and create all default screens from DefaultUserInterface config.

…s screens Move screen defaults (successScreen, defaultFailureScreen, failureScreens) into DefaultUserInterface config. Scenarios can override per-reason failure screens via JSX elements. Simplify OutcomePage to resolve screens from scenario config. Remove OUTCOMES types and FailureScreenResolver.

…th httpStatus propagation Replace single defaultFailureScreen with defaultClientFailureScreen (4xx) and defaultServerFailureScreen (5xx). Propagate httpStatus and message through the error flow from parseHttpRequest to ErrorState. OutcomePage now routes to server failure screen when httpStatus starts with 5.

…appings

…FailureScreen

… single barrel export

…ase and SuccessScreenBase

…solution in FailureScreenBase

…ps separately for type inference

…screen and move Description components to components/

…cenario

melvin-bot · 2026-02-13T14:25:25Z

Hey, I noticed you changed src/languages/en.ts in a PR from a fork. For security reasons, translations are not generated automatically for PRs from forks.

If you want to automatically generate translations for other locales, an Expensify employee will have to:

Look at the code and make sure there are no malicious changes.
Run the Generate static translations GitHub workflow. If you have write access and the K2 extension, you can simply click: [this button]

Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running:

npx ts-node ./scripts/generateTranslations.ts --help

Typically, you'd want to translate only what you changed by running npx ts-node ./scripts/generateTranslations.ts --compare-ref main

…at UNKNOWN_RESPONSE as server error

melvin-bot · 2026-02-13T15:16:21Z

@DylanDylann Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

github-actions · 2026-02-14T00:00:48Z

🚧 @rafecolton has triggered a test Expensify/App build. You can view the workflow run here.

rafecolton

Nicely done! Tested and it works great, including magic code error.

src/components/MultifactorAuthentication/components/OutcomeScreen/OutcomeScreenBase.tsx

src/components/MultifactorAuthentication/components/AuthenticationMethodDescription.tsx

src/components/MultifactorAuthentication/config/scenarios/BiometricsTest.tsx

rafecolton · 2026-02-13T23:45:25Z

src/components/MultifactorAuthentication/config/scenarios/DefaultUserInterface.tsx

+            cancelButtonText: 'common.cancel',
+        },
+    },
+    failureHeaderTitle: 'multifactorAuthentication.verificationFailed',


Why is this here and not part of the failure screens?

This is a simplification to meet the requirement:

For transaction approve/deny failures, use red phone illustration and Transaction failed title and subtitle

Use Transaction failed title (upper left) for transaction approve/deny failures (retain Oops, something went wrong subtitle and humpty dumpty illustration)

Of course, we can do this through the screenshots configuration, but then it would require adding the following to the approve transaction scenario:

defaultClientFailureScreen: <DefaultClientFailureScreen headerTitle="multifactorAuthentication.transactionFailed" />, defaultServerFailureScreen: <DefaultServerFailureScreen headerTitle="multifactorAuthentication.transactionFailed" />, failureScreens: { [CONST.MULTIFACTOR_AUTHENTICATION.REASON.GENERIC.NO_ELIGIBLE_METHODS]: <NoEligibleMethodsFailureScreen headerTitle="multifactorAuthentication.transactionFailed" />, [CONST.MULTIFACTOR_AUTHENTICATION.REASON.GENERIC.UNSUPPORTED_DEVICE]: <UnsupportedDeviceFailureScreen headerTitle="multifactorAuthentication.transactionFailed" />, },

Hm that is an interesting point. We actually should not show the transaction review screen at all if the device is not supported or has no eligible methods (cc @JakubKorytko). It would create a bad UX - one of these two outcomes depending on how we implement it:

Immediately fail the transaction when the user taps Approve - requires the customer to redo the transaction

Let them close the modal and delete the review request from onyx locally - less bad but kinda pointless

For the other scenarios, it's fine to show those errors.

Regarding supplying headerTitle to the defaultClientFailureScreen and defaultServerFailureScreen values - I get what you're saying that we will save a little bit of config by supplying the default failure value once vs multiple times. However, we're already going to need a custom component for each of server/client failure for transaction review in order to supply the title, subtitle, and illustration. So I don't think saving ourselves a single config option is that valuable of an optimization. I'm more inclined to keep this top-level config clean and simple and let each outcome screen be explicit about its headerTitle value.

src/components/MultifactorAuthentication/config/scenarios/DefaultUserInterface.tsx

rafecolton · 2026-02-13T23:51:36Z

src/components/MultifactorAuthentication/config/types.ts

Are there any efficiency implications of storing it this way? e.g. If it is static, do we save having to calculate the element by storing it this way?

src/components/MultifactorAuthentication/Context/Main.tsx

src/pages/MultifactorAuthentication/OutcomePage.tsx

JakubKorytko

Really good job, LGTM, small NABs not worth blocking

src/components/MultifactorAuthentication/components/AuthenticationMethodDescription.tsx

src/components/MultifactorAuthentication/config/scenarios/DefaultUserInterface.tsx

src/components/MultifactorAuthentication/config/types.ts

… outcome types

# Conflicts: # src/components/MultifactorAuthentication/Context/Main.tsx # src/components/MultifactorAuthentication/Context/State.tsx # src/components/MultifactorAuthentication/config/scenarios/DefaultUserInterface.ts # src/components/MultifactorAuthentication/config/types.ts # src/libs/actions/MultifactorAuthentication/processing.ts

Resolve merge conflicts between the type refactor and outcome callback branches: fix stale OutcomePaths import, add missing MultifactorAuthenticationScenarioResponse import, map ProcessResult to ScenarioResponse correctly, and wire default callback into customConfig. Rename all httpCode/httpStatus variants to httpStatusCode for consistency.

codecov · 2026-02-16T16:01:30Z

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/ROUTES.ts	`12.83% <ø> (+0.01%)`	⬆️
src/SCREENS.ts	`100.00% <ø> (ø)`
src/components/Icon/chunks/illustrations.chunk.ts	`0.00% <ø> (ø)`
...onents/MultifactorAuthentication/Context/State.tsx	`6.38% <ø> (+0.26%)`	⬆️
...actorAuthentication/Context/useNativeBiometrics.ts	`92.59% <100.00%> (ø)`
...cation/components/NoEligibleMethodsDescription.tsx	`30.00% <ø> (ø)`
...nts/OutcomeScreen/FailureScreen/defaultScreens.tsx	`100.00% <100.00%> (ø)`
...nts/OutcomeScreen/SuccessScreen/defaultScreens.tsx	`100.00% <100.00%> (ø)`
...cation/components/UnsupportedDeviceDescription.tsx	`33.33% <ø> (ø)`
...tication/config/scenarios/DefaultUserInterface.tsx	`100.00% <100.00%> (ø)`
... and 16 more
... and 26 files with indirect coverage changes

The subtitle translation key requires {authType} params, but SuccessScreenBase called translate(subtitle) without them, causing a crash: "Cannot read property 'authType' of undefined".

…pp restart

github-actions · 2026-02-16T18:17:30Z

🚧 @rafecolton has triggered a test Expensify/App build. You can view the workflow run here.

github-actions · 2026-02-16T18:42:57Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #82297.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-8ba3bd2-db0883a-615aea29a71152fbce6a042c833c31a401b6fdf2/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-8ba3bd2-db0883a-92348e39bcc6b871f545d72c214f8c32e632b792/index.html

Web 🕸️
https://82297.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

chuckdries

Tests pass flawlessly on Android ad-hoc, but the "ReactElement in state" thing is throwing me for a loop and I'm hoping you can help me understand exactly how FailureScreenBase works at all. It calls useMultifactorAuthenticationState, which means it must be rendered as a child of MultifactorAuthenticationStateProvider, but then it itself is stored within the state of that provider. That means it is created, by necessity, outside of that subtree, but it must be okay because it's always actually rendered within that subtree?

chuckdries · 2026-02-16T19:03:38Z

src/languages/params.ts


 type MultifactorAuthenticationTranslationParams = {
-    authType?: AuthTypeName;
+    authType?: string;


Was widening this type necessary? I'm not strongly against it - I don't know that narrowing this set of strings really provided much safety in the first place, but I see that AuthTypeName is still defined and used elsewhere, so why not use it here?

Good catch - we should probably leave it given it is a fixed list

Unfortunately, I had to change this because there's a string that we paste at the end of the translation. Previously, we didn't translate authType into different languages. But after completing the translations, we send the result of translate(AUTH_TYPE_TO_TRANSLATION_KEY(authType)) here, and it returns a string.

rafecolton

Left one comment on something I think should be changed, plus I agree with Chuck's comment about AuthTypeName. Tested well on iOS so I'm going to merge this - we're going to need to make some more changes when adding error screens for the transaction review flows, so we can do the minor refactors then.

rafecolton · 2026-02-16T21:32:09Z

src/components/MultifactorAuthentication/config/scenarios/DefaultUserInterface.tsx

+            cancelButtonText: 'common.cancel',
+        },
+    },
+    failureHeaderTitle: 'multifactorAuthentication.verificationFailed',


Hm that is an interesting point. We actually should not show the transaction review screen at all if the device is not supported or has no eligible methods (cc @JakubKorytko). It would create a bad UX - one of these two outcomes depending on how we implement it:

Immediately fail the transaction when the user taps Approve - requires the customer to redo the transaction

Let them close the modal and delete the review request from onyx locally - less bad but kinda pointless

For the other scenarios, it's fine to show those errors.

Regarding supplying headerTitle to the defaultClientFailureScreen and defaultServerFailureScreen values - I get what you're saying that we will save a little bit of config by supplying the default failure value once vs multiple times. However, we're already going to need a custom component for each of server/client failure for transaction review in order to supply the title, subtitle, and illustration. So I don't think saving ourselves a single config option is that valuable of an optimization. I'm more inclined to keep this top-level config clean and simple and let each outcome screen be explicit about its headerTitle value.

src/components/MultifactorAuthentication/config/scenarios/DefaultUserInterface.tsx

rafecolton · 2026-02-16T22:56:06Z

src/languages/params.ts


 type MultifactorAuthenticationTranslationParams = {
-    authType?: AuthTypeName;
+    authType?: string;


Good catch - we should probably leave it given it is a fixed list

rafecolton · 2026-02-16T23:02:25Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified there are no new alerts related to the canBeMissing param for useOnyx
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
- I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
- I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
- I verified the JSDocs style guidelines (in STYLE.md) were followed
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

github-actions · 2026-02-16T23:06:53Z

🚧 @rafecolton has triggered a test Expensify/App build. You can view the workflow run here.

github-actions · 2026-02-16T23:10:35Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #82297.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-099c41b-db0883a-615aea29a71152fbce6a042c833c31a401b6fdf2/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-099c41b-db0883a-92348e39bcc6b871f545d72c214f8c32e632b792/index.html

Web 🕸️
https://82297.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-02-16T23:12:56Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

dariusz-biela · 2026-02-17T10:38:41Z

@chuckdries

Tests pass flawlessly on Android ad-hoc, but the "ReactElement in state" thing is throwing me for a loop and I'm hoping you can help me understand exactly how FailureScreenBase works at all. It calls useMultifactorAuthenticationState, which means it must be rendered as a child of MultifactorAuthenticationStateProvider, but then it itself is stored within the state of that provider. That means it is created, by necessity, outside of that subtree, but it must be okay because it's always actually rendered within that subtree?

React works in such a way that JSX is really just a configuration that describes which component function to call during rendering.

sucessScreen: <SucessScreenBase title="abc"/>

is exactly the same as:

sucessScreen: {
     component: SucessScreenBase,
     props: { 
          title:"abc"
     }
}

Therefore, this component will only be called in the react renderer call tree, in the place where the successScreen value is inserted in the OutcomePage.

OSBotify · 2026-02-18T00:07:19Z

🚀 Deployed to staging by https://github.com/rafecolton in version: 9.3.21-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

OSBotify · 2026-02-18T22:02:53Z

🚀 Deployed to production by https://github.com/mountiny in version: 9.3.21-4 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

dariusz-biela added 7 commits February 11, 2026 13:21

feat: Add SuccessScreen and FailureScreen base layout components for …

8b278f4

…MFA outcomes

refactor: Use TranslationPaths in screen base components and add crea…

5d94a21

…teScreenWithDefaults factory

feat: Add default outcome screens using createScreenWithDefaults factory

7054d34

Use IllustrationName with lazy loading in base components, make subtitle optional in FailureScreenBase, and create all default screens from DefaultUserInterface config.

melvin-bot bot assigned dariusz-biela Feb 12, 2026

dariusz-biela added 11 commits February 13, 2026 11:45

refactor: Remove OutOfTimeFailureScreen from default failure screen m…

dc86371

…appings

feat: Add MagnifyingGlassSpyMouthClosed illustration to DefaultClient…

da3bf57

…FailureScreen

refactor: Move failure/success screens into OutcomeScreen folder with…

f7b2021

… single barrel export

refactor: Extract OutcomeScreenBase as shared base for FailureScreenB…

ce936d2

…ase and SuccessScreenBase

feat: Add failureHeaderTitle to scenario config with context-based re…

199e9ea

…solution in FailureScreenBase

docs: Add JSDoc to createScreenWithDefaults factory function

a5c3f12

refactor: Change createScreenWithDefaults to accept Component and pro…

4fe620f

…ps separately for type inference

feat: Add try/catch for unhandled errors in MFA process flow

c1b2f78

refactor: Remove unused MFA REASON constants

6935d43

feat: Add AuthenticationMethodDescription for BiometricsTest success …

12c800e

…screen and move Description components to components/

refactor: Remove custom failureScreens override from BiometricsTest s…

33ee2e6

…cenario

dariusz-biela added 2 commits February 13, 2026 15:25

Merge branch 'main' into dariusz-biela/feat/3ds/error-handling

5081dfb

fix: Add authType fallback in AuthenticationMethodDescription and tre…

99551d9

…at UNKNOWN_RESPONSE as server error

dariusz-biela marked this pull request as ready for review February 13, 2026 15:16

dariusz-biela requested review from a team as code owners February 13, 2026 15:16

melvin-bot bot requested review from DylanDylann and trjExpensify and removed request for a team February 13, 2026 15:16

This comment has been minimized.

Sign in to view

rafecolton reviewed Feb 14, 2026

View reviewed changes

JakubKorytko approved these changes Feb 16, 2026

View reviewed changes

dariusz-biela added 8 commits February 16, 2026 12:03

Merge branch 'main' into dariusz-biela/feat/3ds/error-handling

93b5373

feat: Add verificationFailed translations for 3DS error handling

27a30eb

feat: Add authType translations for biometrics test success screen

9d6b334

refactor: Simplify BiometricsTest success screen config

92d5ae4

fix: Use numeric comparison for HTTP 5xx server error check

8b6675c

refactor: Simplify MFA scenario config types with composable base and…

579fa93

… outcome types

dariusz-biela added 2 commits February 16, 2026 17:42

fix: Remove parameterized subtitle from DefaultSuccessScreen defaults

7c6b9fc

The subtitle translation key requires {authType} params, but SuccessScreenBase called translate(subtitle) without them, causing a crash: "Cannot read property 'authType' of undefined".

fix: Dismiss MFA modal directly when scenario context is lost after a…

8ba3bd2

…pp restart

dariusz-biela requested a review from rafecolton February 16, 2026 16:59

chuckdries reviewed Feb 16, 2026

View reviewed changes

rafecolton approved these changes Feb 16, 2026

View reviewed changes

rafecolton merged commit 099c41b into Expensify:main Feb 16, 2026
32 of 37 checks passed

dariusz-biela mentioned this pull request Feb 17, 2026

[NO QA] refactor: remove failureHeaderTitle from MFA scenario config #82708

Merged

51 tasks

OSBotify mentioned this pull request Feb 17, 2026

Deploy Checklist: New Expensify 2026-02-17 #82716

Closed

93 tasks

Conversation

dariusz-biela commented Feb 12, 2026 • edited by rafecolton Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot bot commented Feb 13, 2026

Uh oh!

melvin-bot bot commented Feb 13, 2026

Uh oh!

github-actions bot commented Feb 14, 2026

Uh oh!

This comment has been minimized.

rafecolton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

JakubKorytko left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codecov bot commented Feb 16, 2026 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

github-actions bot commented Feb 16, 2026

Uh oh!

github-actions bot commented Feb 16, 2026

Uh oh!

chuckdries left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rafecolton left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rafecolton commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

Uh oh!

github-actions bot commented Feb 16, 2026

Uh oh!

github-actions bot commented Feb 16, 2026

Uh oh!

OSBotify commented Feb 16, 2026

Uh oh!

dariusz-biela commented Feb 17, 2026

Uh oh!

dariusz-biela commented Feb 12, 2026 •

edited by rafecolton

Loading

codecov bot commented Feb 16, 2026 •

edited by github-actions bot

Loading

rafecolton commented Feb 16, 2026 •

edited

Loading