Forum Discussion

miikka's avatar
miikka
Maven
9 years ago

Updating user profile language through REST API v1 now broken

Hi,

we have been using this bit of code to change the language setting for a user:

<#assign update_lang_setting = rest("/users/self/profiles/name/language/set?value=${language}") />

This has worked well up until version 16.5 but now it seems to be broken or at least not working reliably enough (it's used in the page initialization script so it's hard to see what goes wrong).

 

So has something changed in 16.6 or in 16.7 which could cause this?

 

Cheers,

.M

9 Replies

  • ChiaraS's avatar
    ChiaraS
    Lithium Alumni (Retired)
    9 years ago

    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]

     

     

  • miikka's avatar
    miikka
    Maven
    9 years ago

    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

  • ChiaraS's avatar
    ChiaraS
    Lithium Alumni (Retired)
    9 years ago

    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}") />

     

  • miikka's avatar
    miikka
    Maven
    9 years ago

    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:

  • ChiaraS's avatar
    ChiaraS
    Lithium Alumni (Retired)
    9 years ago

    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.

  • miikka's avatar
    miikka
    Maven
    9 years ago

    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:

  • miikka's avatar
    miikka
    Maven
    9 years ago

    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.

  • ChiaraS's avatar
    ChiaraS
    Lithium Alumni (Retired)
    9 years ago

    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.

  • miikka's avatar
    miikka
    Maven
    9 years ago

    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.