AADB2C Embedded Password Reset: Local account discover is not being fired - azure

Question

We're implementing the embedded password reset, as is the new recommended practice. Once we click the Forgot your password? link the reset sub-journey is invoked as expected.
The reset sub-journy always skips the local account discovery step, where the user verifies their email to access their account information, and jumps directly to the screen to enter a new password - the new password entry then fails, because there is no account to write the new password into.
Our reset password journey is as follows:
<SubJourney Id="PasswordReset" Type="Call">
<OrchestrationSteps>
<OrchestrationStep Order="1" Type="ClaimsExchange">
<!-- This orchestration step never occurs. The user is never prompted for their email address. -->
<ClaimsExchanges>
<ClaimsExchange Id="PasswordResetUsingEmailAddressExchange" TechnicalProfileReferenceId="LocalAccountDiscoveryUsingEmailAddress" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="NewCredentials" nicalProfileReferenceId="LocalAccountWritePasswordUsingObjectId" />
</ClaimsExchanges>
</OrchestrationStep>
</OrchestrationSteps>
</SubJourney>
Our code, so far, is lifted directly from the tutorials and sample code. How can we fix this issue, and has anyone else encountered the same problem?

Answer 1

Your question has been solved, post it as the answer to the end of the thread:
This is a bug in the B2C system - the initial combined sign in and
sign up step seems to set the email claim, even if the user hits the
"forgot your password" link. The
LocalAccountDiscoveryUsingEmailAddress profile attempts to use the
(blank) claim without prompting the user to enter an address, jumping
to the password write step but not picking up an account to write the
password to. We worked around this by creating a new resetEmail claim
used only by the account discovery and password write profiles.