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.
