Page MenuHomePhabricator

Login is intermittently not persisting cross-wiki
Closed, ResolvedPublic

Description

While testing on testwiki, I noticed that my log in was occasionally dropping swapping between the different SUL wikis. eg:

  1. Log in on meta
  2. Confirm I am logged in on enwiki
  3. Note that I am now logged out on testwiki

Attempting to log into testwiki would require me to re-log in, at which point I would see a similar pattern across other wikis. I could still visit meta logged in on the original tab but attempting to navigate to meta from my un-logged in session from test would show me logged out. Occasionally (I think, but did not confirm, trying to re-navigate to a wiki i was already logged into), it would invalidate my session and I would have to log in again but was still unable to freely move between wikis.

I noticed that wgHostnames showed coddfw sometimes and eqiad others. I could resolve my issue by pinning myself to the debug servers.

Event Timeline

T424935 may be the same symptom?

Noting that T423687 bumped the CentralAuthUser cache version in wmf.26, in case that is relevant.

matmarex subscribed.

T424935 was caused by a cache inconsistency between wmf.26 and wmf.24 wikis (there was no wmf.25). Same with T424930, which indicates that this may have caused some login problems when moving between wmf.26 and wmf.24 wikis. However, I don't think you could avoid that issue by pinning yourself to the debug servers, so that's a bit surprising. Maybe that was just a fluke.

Anyway, can you still reproduce the problem now?

STran claimed this task.

However, I don't think you could avoid that issue by pinning yourself to the debug servers, so that's a bit surprising. Maybe that was just a fluke.

Maybe; I was testing by looking for my feature which made some assumptions about my logged in state and host consistency. I mostly noticed that if I was being served from one server (can't recall if it was eqiad or codfw), everything behaved as expected, but not on the other.

Anyway, can you still reproduce the problem now?

Just tested again and it looks to have resolved. Seems like it was the cache inconsistency issue.