Environment: Nightly Device: Sony Xperia Z2 (Android 5.0.2 ); Build: Nightly 48.0a1 (2016-04-03); Steps to reproduce: 1. Go to settings 2. Enter account credentials in order to log in 3. Try to sign in Expected result: User is signed in Actual result: User is not signed in and "Unexpected error" message is displayed Notes: Please note that this issue occurs on all devices, phone and tablet

Firefox Accounts is currently experiencing a partial service outage, the operations team is on the case but I don't yet have an expected time for return of service. Latest service status is viewable at https://status.services.mozilla.com/

it appears that the logging of this error to sentry is also failing, due to the code using GET instead of POST, resulting in "414 request too large".

Bug 1261761 was reported in #MOC, and after an escalation to CloudOps, we've been notified that the team has been working on restoring service but with no definite ETA as of yet.

We appear to be successfully back online, marking this RESOLVED/FIXED.

Now I got: "Attempt limit exceeded" error message.

Still doesn't work. Thoughts?

[Tracking Requested - why for this release]: Release Management may be interested in this

On the mobile side, a work-around has been found to avoid the "Attempt limit exceeded" error message when trying to log in. A hot-spot internet access has been created and if connected to it, i was able to log in to my sync account. When multiple devices are connected to a wi-fi and trying to log in with multiple sync accounts on different devices, the network generates only one exiting IP and maybe the server recognizes it as a conflict. P.S. Is there any way to hard delete the connection attempts from our IP?

> Is there any way to hard delete the connection attempts from our IP? There's no way for you to clear the rate-limiting yourself. I can see what's possible on our end - please file an employee-confidential bug, list the IP addresses you need, and cc me.

Isn't this still an issue though? It seems to me we may be reaching this limit quite easily.

Yes, we're also working on a better long-term solution to prevent this from happening so easily in the future, but unfortunately it's a tricky balancing act

We've deployed some more fixes for the rate-limiting logic, and are seeing a much lower overall rate of "attempt limit exceeded" errors. Can you confirm whether things are working better from your side?

Things seem to work fine now. I'll let you guys know if we run into additional problems. Thank you for working on this!

Sounds like this was fixed while 48 was still in nightly.

This was a server side fix... after ~1 month we've had no other issues reported with this.