When upgrading from 2021.1 to a newer version existing users get the following message:
Error: Could not parse locale cookie value "c=en-US|
uic=enUS|defaultDateSeparator=.|defaultTimeSeparator=:|defaultDateTimeSeparator=|
defaultDateSequence=DayMonthYear|defaultLongDateFormat=dd.MM.yyyy HH:mm:ss|defaultShortDateFormat=dd.MM.yyyy|
defaultTimeFormat=HH:mm:ss".
Error: Parameter named "defaultDateTimeSeparator" was not found
It should fallback.
The error is not caused by an old cookie as suggested but rather the fact that
defaultDateTimeSeparator parameter is set to an empty string. Not sure how this happened, because the default is a white space.
It happened on an upgraded installation. The users had to first switch a language back and forth to mitigate the error message. I still think it was related to an old cookie.
The cookie you posted is definetly the new one. Perhaps there was another message before this one?
No. But I had to switch a language back and forth. Does that mean that when I login without explicitly selecting a language that I get some defaults instead of the settings set for the currently selected language?
if your cookie does not include the new parameters, you should get a new one automatically. If you don’t selectet a language you will get the default language and all settings that go wtih it. The defaults are resolved from appsettings.json, if there is something missing in the appsettings.json the defaults are derived from cs-CZ
Can you provide an example cookie or model?.
Since we are doing this we might as well look into what characters should be allowed in the formatting settings. The settings are transfered with a cookie, so there are some limitations:
May be we should also try to get a new one whenever we get an error while parsing the locale cookie. And only display an error message if the new cookie causes the errors as well. There are some check now, but they just check whether the user has an old format of the cookie (will have to be updated when the cookie changes).
So the question is. How much should we complicate this?
I would vote for the suggested behaviour – retrying to load a cookie from the server and then displaying an error if it is still bad.
@washi what is your suggestion?
I agree with suggested solutions. It might be a good idea to log the problem - at least on the client’s console.
From what I see we now fallback to long date format whenever the format is unknown in the model instead of throwing an exception. In what cases can this happen?
I accidentally changed the behavior in a previous commit. So should we throw an exception here?
When we add something to the enum and forget to translate it in the XML builder we would not get an error. Instead, we would get some default behaviour. This would be quite confusing for the developer. I would throw an exception so everybody knows what we’ve forgot.
I tested and found no problems.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.