login message sent but account is not created when verification email bounces immediately

[ncalexan]

Choose an email that bounces immediately -- the flow will "unwind" back to the "Sign up" screen (with an error message). That's fine, but I'm seeing a login message sent to context=fx_fennec_v1 after the "Choose what to Sync" flow is completed, but before the unwind, and before the account is created on the server. That's badness.

@vlad @shane-tomlinson @leibovic

[shane-tomlinson]

I somewhat feel it's up to the device to handle this case. If we wait until after the first poll to see if the the email has bounced and only then do we send the login message, the user could have already shut the FxA window and the device would never receive the message. We could try to do something a bit more tricky, but it feels like we'd end up shooting ourselves in the foot.

IIUC, the account must be created and then deleted, otherwise no uid, sessionToken, unwrapBKey, etc could ever be sent in the login message.

[vladikoff]

@ncalexan Do you think it is realistic to use Push for this in the future? To notify about "Email bounces", "Account Deletion" etc?

[vladikoff]

A bit related to the comment above: https://bugzilla.mozilla.org/show_bug.cgi?id=1221703

[shane-tomlinson]

Some discussion from IRC:

15:01 <vladikoff> stomlinson, "if we wait until after the first poll to see if the the email has bounced", sometimes the bounce might not happen on first poll
15:01 <stomlinson> vladikoff: say more?
15:02 <vladikoff> stomlinson, basically we cannot safely check "if bounced"
15:02 <stomlinson> vladikoff: that's my thought too.
15:02 <vladikoff> stomlinson, should we provide a message back that "fxaccounts:email_bounced_revert_everything"
15:02 <stomlinson> vladikoff: the only thing we really know definitively is if the original signup failed, or if the email bounced and the user still has the "go confirm your email" tab open.
15:05 <stomlinson> vladikoff: I'm not totally convinced of the need b/c the device is polling in the background at the same time as us. Even if the front end is still open and we learn the email bounced, the device should find out within a few second of us that fact too. Perhaps the message is a good idea though, because we could find out 10 seconds before the device, the user
15:05 <stomlinson> could feasibly go back in that amount of time and enter a new email before the device re-polls
15:05 <stomlinson> vladikoff: the other advantage a message like that would give us is the ability to place an "I entered the wrong email address" button on the "confirm your email" screen. If the user clicks that, inform the browser so they can reset their state.
15:06 <stomlinson> vladikoff: so in the last 2 minutes, I've convinced myself a WebChannel message is a good idea and not sending the "login" message is a bad idea.
15:06 <stomlinson> or I should say "delaying the sending of the login message"
15:07 <vladikoff> stomlinson, I wonder if we can use web push to let fennec know it bounced
15:07 <vladikoff> stomlinson, or whatever other push
15:08 <stomlinson> vladikoff: I was wondering that too. With push the devices are going to stop polling anyways and will find out pretty quickly that the email bounced.

[rfk]

@shane-tomlinson and @vladikoff pointed this out in IRC, and I wanted to record it for a little more context context on why things are how they currently are. This assumption is incorrect:

before the unwind, before the account is created on the server.

The account does get created on the server. It's just that when the server receives a hard-bounce notification for that email address, it deletes the account. The content-server detects this and unwinds the flow.

It could be that this bug is a special-case of "handle deleted accounts better" in our client-facing flows, like #3057.

It could also be that we should do something smarter with bounced emails, like put the account into a different "invalid email" state per mozilla/fxa-auth-server#721.

[ncalexan]

On Thu, Nov 5, 2015 at 1:13 PM, Ryan Kelly notifications@github.com wrote:

@shane-tomlinson https://github.com/shane-tomlinson and @vladikoff
https://github.com/vladikoff pointed this out in IRC, and I wanted to
record it for a little more context context on why things are how they
currently are. This assumption is incorrect:

before the unwind, before the account is created on the server.

The account does get created on the server. It's just that when the server
receives a hard-bounce notification for that email address, it deletes
the account. The content-server detects this and unwinds the flow.

I'm not really against doing this. It's just exposing a thing that
neither the Android or iOS client handle smoothly: accounts being deleted
on the server.

[rfk]

@ncalexan any thoughts on how to move forward with this? It doesn't sound like just eliminating the "login" message is the right thing to do here, even if it were possible to do reliably. Does this bug need to morph into a "handle deleted accounts better" action? (either on our side, your side, or both)

[ncalexan]

On Mon, Nov 16, 2015 at 2:27 AM, Ryan Kelly notifications@github.com
wrote:

@ncalexan https://github.com/ncalexan any thoughts on how to move
forward with this? It doesn't sound like just eliminating the "login"
message is the right thing to do here, even if it were possible to do
reliably.

Yes, I agree. It worries me that the server kills accounts quite so
quickly, but handling emails that "come online" is ridiculous, so here we
are.

Does this bug need to morph into a "handle deleted accounts better"
action? (either on our side, your side, or both)

We already had https://bugzilla.mozilla.org/show_bug.cgi?id=999198 on file,
and we'll move forward with that. Thanks for checking in!

[rfk]

OK great. On our side, we'll push forward with something like mozilla/fxa-auth-server#721 as a better way of dealing with bounced emails than just deleting the account. It will probably come as part of work to allow you to change the email address on your account, which I'm sure will raise more exciting questions about the content<->browser protocol, but that's for another bug...