I have yet to roll out 4.1 to my team. That may happen this coming weekend or during labor day, since no one will be working. I’ll reply to this thread once that roll out happens and I can report my findings.
@jasonblais I am currently unable to reproduce the looping issue. It’s possibly fixed. Unfortunately two things changed at once so I don’t know which it was, if either:
some additional certificates were installed on the gitlab server to help with trust issues
I added the “api” scope to the application
I’ll keep a lookout on the logs, but, things do seem to have improved!
I’m still seeing this issue with with one user with Mattermost 4.1.0.
I can reproduce it after clearing cache and in Chrome incognito mode. When I try to login with the affected user id, I see no log messages in the server log. I cannot say if this error started after session expiry. Since the user cannot log in, I cannot access the sessions view in the account settings.
In the Chrome developer console are several “Invalid language tag” errors. The user probably set the language to german. I thought this error was fixed in 4.1.0?
I spoke too soon - looking in the logs this morning I can see more examples of the log spamming from the refresh loop, so some users are still affected it seems.
Yeah, it sounds like similar to Gitlab SSO localization issue before which was fixed by setting currentLocale to en. Could you post the logs your seeing at Chrome console?
When trying to log in, I see this error five times in the chrome developer console:
channel_utils.js:314 Uncaught (in promise) RangeError: Invalid language tag:
at new Collator (native)
at String.localeCompare (native)
at o (http://chat.subshell.com/static/main.2b75939e681d6c1cdd03.js:1:582666)
at Array.sort (native)
at Array.sort (http://chat.subshell.com/static/main.2b75939e681d6c1cdd03.js:1:1168689)
at x (http://chat.subshell.com/static/main.2b75939e681d6c1cdd03.js:1:582785)
at k (http://chat.subshell.com/static/main.2b75939e681d6c1cdd03.js:1:583564)
at s (http://chat.subshell.com/static/main.2b75939e681d6c1cdd03.js:1:579371)
at http://chat.subshell.com/static/main.2b75939e681d6c1cdd03.js:1:530357
at Set.forEach (native)
While looking at the Users table, I noticed that the affected user is the only one where locale is not set. So this seems to be the culprit in my case.
Yeah, it should not be empty. Better to have it set to de same as your DefaultClientLocale. Let us know if that solves the problem.
I wonder how this user ended up with empty Locale. Was it created from usual user registration, bulk upload/import, switch from other auth service, or was changed only during server upgrade?
Everything seems fine for now. The issue though is still that on my end before the upgrade, this issue was very sporadic on when it would be encountered. So it’s hard to know certainly that it has been fixed. Only time will tell I guess.
I’ve tried forcing this issue to happen by manually restarting the MM Server (in the docker container) and manually restarting the reverse proxy server (Apache2), and I haven’t been able to reproduce it anymore.
@lindy65 I don’t have a way to reproduce it right now, so until a user tells me about it and lets me capture some Chrome logs before they clear their caches, I have no way to capture anything unfortunately. I did report some here at the start.
@saturnino you said a potential fix is setting currentLocale to en - can you expand on what you mean? What action would I take?