Closed Bug 1261753 Opened 5 years ago Closed 5 years ago

"unexpected error" when logging in to accounts.firefox.com

Categories

(Cloud Services :: Server: Firefox Accounts, defect)

defect
Not set
normal

Tracking

(firefox45 unaffected, firefox46 unaffected, firefox47 unaffected, firefox48 fixed)

RESOLVED FIXED
Tracking Status
firefox45 --- unaffected
firefox46 --- unaffected
firefox47 --- unaffected
firefox48 --- fixed

People

(Reporter: u549602, Unassigned)

References

Details

Attachments

(1 file)

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
Component: General → Server: Firefox Accounts
Product: Firefox for Android → Cloud Services
Version: Trunk → other
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/
OS: Android → All
Hardware: ARM → All
Summary: Logging in with an account does not work → "unexpected error" when logging in to accounts.firefox.com
Duplicate of this bug: 1261761
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.
Group: infra
Duplicate of this bug: 1261768
Group: infra
Duplicate of this bug: 1261779
Duplicate of this bug: 1261824
Duplicate of this bug: 1261878
Duplicate of this bug: 1261871
We appear to be successfully back online, marking this RESOLVED/FIXED.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Now I got: "Attempt limit exceeded" error message.
Still doesn't work. Thoughts?
Flags: needinfo?(rfkelly)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
[Tracking Requested - why for this release]: Release Management may be interested in this
tracking-fennec: ? → ---
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.
Flags: needinfo?(rfkelly)
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?
Flags: needinfo?(florin.mezei)
Things seem to work fine now. I'll let you guys know if we run into additional problems. Thank you for working on this!
Flags: needinfo?(florin.mezei)
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
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.
You need to log in before you can comment on or make changes to this bug.