When MediaWiki receives a request with an invalid session, it starts a new anonymous session. In the case of CookieSessionProvider this means changing the session cookie and deleting the other authentication-related cookies.
The session ID is reset (ie. session data is moved to a new address) on certain changes, to prevent [[https://en.wikipedia.org/wiki/Session_fixation|session fixation]] attacks. This means the old session becomes invalid, while the user still has a valid session. If, due to race conditions, the user makes a request with the old session ID, MediaWiki will reset the browser's session cookies to a new anonymous session, effectively logging the user out.
An example locally reproduced by @kostajh (log lines edited for brewity, full version in P18716):
```
[#1]
[2022-01-13T08:11:18.252634+00:00] wfDebug.DEBUG: Start request GET /w/index.php?title=Special%3ACreateAccount
[2022-01-13T08:11:18.307820+00:00] cookie.INFO: setcookie: "my_database_session", "espu714u2dvic2ie6vu9m97dmo9bl0ik", "0", "/", "", "", "1", "" {"private":false}
[#2]
[2022-01-13T08:11:21.323528+00:00] wfDebug.DEBUG: Start request POST /wiki/Special:CreateAccount COOKIE: my_database_session=espu714u2dvic2ie6vu9m97dmo9bl0ik
[2022-01-13T08:11:22.112614+00:00] memcached.DEBUG: MemCache: delete my_database:MWSession:espu714u2dvic2ie6vu9m97dmo9bl0ik (DELETED)
[2022-01-13T08:11:22.114827+00:00] cookie.INFO: setcookie: "my_database_session", "1f0cdurlkvd1murbnqggrk7dj4t8borm", "0", "/", "", "", "1", "" {"private":false}
[2022-01-13T08:11:22.121394+00:00] memcached.DEBUG: set my_database:MWSession:1f0cdurlkvd1murbnqggrk7dj4t8borm (STORED)
[#3]
[2022-01-13T08:11:22.272413+00:00] wfDebug.DEBUG: Start request GET /w/api.php?action=query&format=json&list=users&... COOKIE: my_database_session=espu714u2dvic2ie6vu9m97dmo9bl0ik
[2022-01-13T08:11:22.283378+00:00] session.INFO: Persisting session due to no pre-existing stored session
[2022-01-13T08:11:22.283852+00:00] cookie.INFO: setcookie: "my_database_session", "d388lh2in8ueofut7tj9s3027bbv7fv7", "0", "/", "", "", "1", "" {"private":false}
[#4]
[2022-01-13T08:11:22.292671+00:00] wfDebug.DEBUG: Start request GET /w/index.php?title=Special:WelcomeSurvey&... COOKIE: my_database_session=1f0cdurlkvd1murbnqggrk7dj4t8borm; my_databaseUserID=2193; ...
[#5]
[2022-01-13T08:11:22.291742+00:00] wfDebug.DEBUG: Start request POST /w/api.php COOKIE: my_database_session=espu714u2dvic2ie6vu9m97dmo9bl0ik
[2022-01-13T08:11:22.300403+00:00] session.DEBUG: SessionBackend "nap3nguq4k57nknlm3tek853vntk78jb" metadata dirty due to ID reset (formerly "espu714u2dvic2ie6vu9m97dmo9bl0ik")
[2022-01-13T08:11:22.301946+00:00] cookie.INFO: setcookie: "my_database_session", "nap3nguq4k57nknlm3tek853vntk78jb", "0", "/", "", "", "1", "" {"private":false}
[#6]
[2022-01-13T08:11:26.591258+00:00] wfDebug.DEBUG: Start request POST /wiki/Special:WelcomeSurvey COOKIE: my_databaseUserID=2193; ... my_database_session=nap3nguq4k57nknlm3tek853vntk78jb
```
# User visits the account creation page, gets a temporary anonymous session (session ID `espu...`) to be used for the login process.
# User submits username and password, using the anonymous login session `espu...`. The logged-in session `1f0c...` gets created, the old session gets deleted, the session cookie for the new session gets sent.
# The user gets a post-login redirect to the GrowthExperiments welcome survey form. The redirected request uses the logged-in session `1f0c...`.
# Belatedly, the password validation API (triggered by the change event of the password field on the login page) runs. It uses the login session `espu...` - the browser sent the request before the login succeeded, but the server only processes it afterwards. Since a (by now) non-existant session is referenced, MediaWiki resets the session to a new anonymous session, `nap3...`, and tells the browser to update cookies accordingly.
# User submits the welcome survey. The browser uses the anonymous session `nap3...` it was told in the previous request to use. By this point the user is logged out (the logged-in session still exists but the browser has lost the key to it).
This was tested with account creation as we discovered it when QA-ing that, but it should equally apply to other workflows with a session ID reset, such as a login or a permission change. Although for those it's probably mitigated by the "remember me" login option (ie. the user having a cookie with a hash of the `user_token` DB field) or the central login session in the case of CentralAuth - both of those can make a session with a session cookie referencing a non-existent session store object valid, as there's other authentication data in the session to fall back to.