Page crashes when dark lang is set to partially supported language

We've seen bursts of JS errors in the Accounts MFE relating to Beta Languages/dark_lang, specifically in this line:

frontend-app-account/src/account-settings/BetaLanguageBanner.jsx

Line 52 in 0e7d2c0

const isSavedLanguageReleased = savedLanguage.released === true;

This is correlated to traffic from certain countries, and I was able to produce a page crash (although not that specific error) by setting my language to de in https://courses.edx.org/update_lang/ -- this causes the page to blank and spew errors in a tight loop.

Post resolution:

Restore New Relic alert policy. See comment.

This issue is caused by absence of beta language / dark_lang object literal in siteLanguageList at src -> accout-settings -> site-language -> constants.js.

Whenever we set de at https://courses.edx.org/update_lang/ and load the Accounts MFE page, it fetches de as dark-lang parameter in API response. Later, when BetaLanguageBanner.jsx component tries to render, it looks for / filters de object literal in siteLanguageList via redux-selectors, but finds no such data and just assigns undefined to savedLanguage. As a result, the code breaks at the line as mentioned in the above comment (no released property in undefined object).

For more clarification, I added de language literal in siteLanguageList and the component started rendering fine, with no page crash errors. Now, as of initial work, we need to add language literals to support beta languages in Accounts MFE. In the last, I've a question too. What do we mean by partially supported language? It means MFE translations for the beta languages are in progress? Or is it mean specific language support is only available for certain MFEs?

Could this have been a side effect of #641 , which updated the language list in the Makefile but not in constants.js? If so, we should update the latter to match and also check any other repos where the language list in the Makefile was updated to see if similar changes are needed there.

From @timmc-edx:

(Alert policy https://onenr.io/02R5NWbvkjb is currently set to 30 minutes for 20% error rate, and should probably be restored to 5 minutes.)

I'm guess we'll want to do that once this has been closed.

Created this PR to support affected languages that made crash the website. Tested and reviewed, working fine.

Before we merge, I've a question; If you look in the PR code, there is a released key in siteLanguageList. If the value is set to false, only then it will render BetaLanguageBanner. My question is who can help us determine what languages need to be set as false here?

Hi @ishahroz , who can we flag this to in order to get your question answered? This is affecting many edX.org learners and our Support team continues to receive reports of this.
Checking in Snowflake, since this was raised last some 30,000+ learners whose profile language is affected (de, it, pt, hi, fr-ca) have logged into their accounts.

I think that the fastest fix we can do is to update the language list to have any released value for the affected languages. Even if it's incorrect, that will make the page start loading again for these users. I'd recommend erring on the side of beta for this fix, until we can get the most correct answer.
I'm not sure this is the right place to look, but it looks like the dark_lang Django app in edx-platform stores the beta/released language distinction (and provides the UI for selecting a dark-launched language). According to the most recent data in production:

select released_languages, beta_languages from dark_lang_darklangconfig order by change_date desc limit 1;

Released: en, fr, zh-cn, es-419, ar, de-DE, tr-TR
Beta: pt-br, ko-kr, ca, he, id, pl, ru, th, uk, sw, ja-JP, eu-ES, lt-LT, lv, ka, nl, it

The code should also tolerate unknown or unexpected languages. The lists will inevitably get out of sync, and we need to be able to show the page even if the language cookie is out-of-range or invalid. This would be the more complete fix.

For an initial quick fix, perhaps if (!savedLanguage) return null -- would that at least unbreak the page?

(This would just be temporary -- I think a more correct fix would be to still show the banner for unknown language codes. It would have to tolerate not having language names, so it would be a little bit more work.)

@ishahroz It looks like this was moved to Done on the FED-BOM board, should the issue also be closed now?

Hi @jmbowman learners are still reporting this error and Support can still reproduce it, I don't believe this is resolved.

Hi @beckrecca , as communicated over the Slack, can you please confirm here if the fix is working fine now? Thank you.

Thanks for tagging me here! Yes I can confirm this is resolved on PROD thank you for your help.

Closing this issue as it is resolved.