Updating user profile language through REST API v1 now broken

hi miikka

don't think something changed around that. 

I had a quick look at the logs and I see some messages like this, so maybe the problem is somewhere else in the common init logic:

The following has evaluated to null or missing: ==> SUPPORTED_LANGUAGES_MAPPING[trimmedLang] [in template "language-detection.ftl" at line 44, column 29]

Failed at: #local supportedLang = SUPPORTED_LANG... [in template "language-detection.ftl" in function "isLanguageSupported" at line 44, column 5] - Reached through: #local checkLang = isLanguageSupporte... [in template "language-detection.ftl" in function "getAcceptLanguage" at line 67, column 13] - Reached through: #assign lang = getAcceptLanguage(false) [in template "Common.init" at line 58, column 9]

Thanks ChiaraS

This specific error message is related to the same topic but applies only for anonymous users. And it's kind of expected as not all languages coming in browser settings are supported. But we can improve the logic so there won't be error messages like this in the log.

Unfortunately the problem we have is related to authenticated users and that bit of code is not executed for them.

Cheers,

.M

I see... I would try to use the user.id instead of self and use restadmin to see if it makes a difference:

<#assign update_lang_setting = restadmin("/users/id/${user.id?c}/profiles/name/language/set?value=${language}") />

Just tried this but looks like it makes no difference unfortunately. The weird thing is that we haven't touched this code in months and it suddenly started to cause issues. But will keep on troubleshooting :smileyhappy:

hi miikka

i tried this on another 16.7 instance and works as expected, so the problem is related to some other logic failing inside the common init section.

Thanks ChiaraS.

And I agree, the API call itself should be trivial and should work as expected.

We haven't changed the related code in several months so I was thinking about it could be because of some other changes (Freemarker updates, object updates etc) which would make the code work differently now as the problems have surfaced.

Another explanation could be horizontal scaling so that the information gets updated in the DB but then there's a delay to propagate the change between DB instances.

Will continue investigating, any pointers are still welcome :smileyhappy:

One interesting observation from our investigations, this could be somehow related to caching.

As when you change language using one of the two dropdown menus, a URL like this will be called:

https://community-stage.skype.com/?setlang=XX

where XX is the identifier of the selected language, for example 'en', 'de', 'es' and so on.

For authenticated users on our stage changing language does not really work at the moment but seems to work (could 100%) when you force the page to be loaded, for example:

https://community-stage.skype.com/?setlang=es?ffdsdfsdfsdfsdf

So I'm wondering whether the request gets cached and instead of actually executing the related business logic, a cached response is returned instead.

hi miikka

one thing for sure, is that if you set the language for a user in the common init, you will have to trigger a refresh of the page if you want that to be applied to the current page.

Hi ChiaraS,

yes, we are doing a redirect to a new page after the API call to save the changed language. And it more and more looks like it's related to some caching on some level, just need to understand where exactly.