Impossible to type in reset password field when custom connection resolver is defined (>= 11.31)

[avinesse]

Describe the problem

Starting on v 11.31 :
When clicking "forgot password?" on the lock, it's impossible to type in the email field when a connectionResolver is defined in lockOptions.
Our connection resolver is defined as follows :

    connectionResolver: function (username, context, cb) {
      var isAdmin = /\+admin@anon.org$/.test(username);
      if (isAdmin) {
        // If the username is xxx+admin@anon.org, the connection used will be the `anon-userdb` connection.
        cb({type: 'database', name: 'anon-userdb'});
      } else {
        // Use the default approach to figure it out the connection
        cb(null);
      }
    },

Reverting to v11.30 works fine

What was the expected behavior?

Users should be able to type an email.

Environment

• v11.31 or 11.32
• In Universal Login : https://cdn.auth0.com/js/lock/11.31/lock.min.js
• Custom connection resolver is defined
• I feel this PR [SDK-2823] Fix password reset when using custom connection resolver #2048 from @stevehobbsdev could be the culprit, as it has changed behavior in 11.31

[stevehobbsdev]

Thanks for the report @avinesse, let me take a look this week.

[Camsteack]

Hi !
Thanks for fixing the issue but there seems to be a new bug following this release. I can now type the email in the reset password field but the connection used for the reset password is not correct anymore. I have the same logic as described above but when using the cb(null); callback it's not selecting the default connection anymore ?
Thanks

[Camsteack]

So I managed to pinpoint the behavior:

• If I try to reset the password directly then the wrong connection is being used.
• If I try to first login with the user, it fails because I can't remember the password then I trigger the password change flow, it is using the correct connection.

[avinesse]

Hi @Camsteack I've tried reproducing your problem with the new version but it seems to work fine on my end (I mean I see the correct connection in the payload of the POST /change_password request).
Can you share you connectionResolver to see if anything is different?