[firebase_ui_auth] - exception is only throw one time when using startMFAVerification

[wer-mathurin]

Is there an existing issue for this?

• [x] 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

[wer-mathurin]

I provided a PR #482 for this.

[wer-mathurin]

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 https://github.com/firebase/FirebaseUI-Flutter/pull/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[bot]]

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?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[github-actions[bot]]

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?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[russellwheatley]

@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]

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<UserCredential>....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 :-)