Repository navigation
[firebase_ui_auth] - exception is only throw one time when using startMFAVerification #481
Description
Is there an existing issue for this?
- I have searched the existing issues and found no duplicates.
What plugin is this bug for?
Firebase UI Auth
What platform(s) does this bug affect?
Web
List of dependencies used.
flutter pub deps -s list
Steps to reproduce
if you have this in your actions:
AuthStateChangeAction<MFARequired>((context, state) async {
try {
await startMFAVerification(
resolver: state.resolver,
context: context,
);
} on FirebaseException catch (e) {
if (!context.mounted) return;
ScaffoldMessenger.of(context).hideCurrentSnackBar();
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: ErrorText(exception: e),
),
);
}
}),
The Exception only only catch the first time as you can see it:
If you press a second time on the validation button
The Exception is not raised to the previous catch statement....but print to the console
Expected Behavior
The the error as many time needed.
One you have an error, In was expecting form this helper method to restart:
provider.sendVerificationCode(
hint: hint as fba.PhoneMultiFactorInfo,
multiFactorSession: session,
action: AuthAction.none,
);
Otherwise once you have an error, you need to go to the previous page and type correctly the pin.
I'm expecting user to sometime do mistakes when entering the code, so this can be very annoying from an end user perspective.
Actual Behavior
Only trigger one time
Additional Information
No response
Activity
wer-mathurin commentedon Mar 14, 2025
I provided a PR #482 for this.
wer-mathurin commentedon Apr 2, 2025
Additional information.
@russellwheatley
The problem came from the way the implementation is done, the code validation can only be executed once otherwise you will get an exception that the Completer is already done !!!
The provided #482 resolved that, but not in a clean way :-(
We did it in our codebase a more clean way. I can update the PR accordingly, but need to know if someone will look at it or do something about it.
github-actions commentedon Apr 30, 2025
Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require attention?
Thank you for your contributions.
github-actions commentedon May 30, 2025
Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require attention?
Thank you for your contributions.
russellwheatley commentedon Jul 17, 2025
@wer-mathurin - You mentioned that you have a cleaner way of doing it. If you update the PR, I will take a look. Although I would prefer it isn't a breaking change if possible 😄
wer-mathurin commentedon Jul 20, 2025
Our final implementation can't be done in the library, because we rely on a state management solution....so the provided PR is fair enough...
What I dislike with my PR is the relocation of a new instance of the Completer.....is working now but may cause bugs as the Library evolve over time. In the current implementation the Completer is acting as a waiting state before exiting with the value...
Also I missed adding a test for that. I need to look at how it have need implemented in the library, to make it integrated!
@russellwheatley : any thoughts on how to test this?
This is an helper method, so I'm wondering if we can consider changing the signature? As an example, it return a Future....this mean it will always return something....
What do you think about changing it to be nullable? This way we can add named parameters, like qteAttemps....so this way the future will complete after the numbers of attempts provided by the user....this can prevent too many attempts from firebase when entering too much invalid SMS code :-). This will lead to a better experience :-)
demolaf commentedon Sep 25, 2026
Closing this as resolved in PR #482.