Has someone deleted the master branch

[nate-river123]

Hi team, we use ex_cldr package with the following version: 2.17.2
In this version the install.ex file defines the use of master branch to download the locales. (Line: 251).

Has someone deleted the master branch?

We are noticing the following issue.

15:54:55.942 [error] Failed to connect to 'raw.githubusercontent.com' to download locale "vi". Reason: {:tls_alert, {:handshake_failure, 'TLS client: In state certify at ssl_handshake.erl:1783 generated CLIENT ALERT: Fatal - Handshake Failure\n {bad_cert,max_path_length_reached}'}}
Generating AdsService.I18n for 5 locales named ["en", "id", "root", "th", "vi"] with a default locale named "en"

== Compilation error in file lib/i18n.ex ==
** (RuntimeError) Locale definition was not found for id
    (ex_cldr 2.17.2) lib/cldr/config/config.ex:1286: Cldr.Config.do_get_locale/2
    (ex_cldr 2.17.2) lib/cldr/config/config.ex:1896: Cldr.Config.decimal_formats_for/2
    (elixir 1.11.2) lib/enum.ex:1399: Enum."-map/2-lists^map/1-0-"/2
    (elixir 1.11.2) lib/enum.ex:1399: Enum."-map/2-lists^map/1-0-"/2
    (ex_cldr 2.17.2) lib/cldr/config/config.ex:1885: Cldr.Config.decimal_format_list/1
    (ex_cldr_numbers 2.13.2) lib/cldr/number/formatter/decimal_formatter.ex:778: Cldr.Number.Formatter.Decimal.define_to_string/1
    (ex_cldr_numbers 2.13.2) lib/cldr/number/backend/decimal_formatter.ex:52: Cldr.Number.Backend.Decimal.Formatter.define_number_module/1
    (ex_cldr_numbers 2.13.2) lib/cldr/number/backend/compiler.ex:11: Cldr.Number.Backend.define_number_modules/1
    (ex_cldr 2.17.2) lib/cldr/config/config.ex:2246: anonymous fn/3 in Cldr.Config.define_provider_modules/1
    (elixir 1.11.2) lib/enum.ex:2181: Enum."-reduce/3-lists^foldl/2-0-"/3
    (ex_cldr 2.17.2) lib/cldr/config/config.ex:2244: Cldr.Config.define_provider_modules/1
    (ex_cldr 2.17.2) expanding macro: Cldr.Backend.Compiler.__before_compile__/1

[kipcole9]

15:54:55.942 [error] Failed to connect to 'raw.githubusercontent.com' to download locale "vi". Reason: {:tls_alert, {:handshake_failure, 'TLS client: In state certify at ssl_handshake.erl:1783 generated CLIENT ALERT: Fatal - Handshake Failure\n {bad_cert,max_path_length_reached}'}}

The message indicates that a secure connection can't be established to GitHub. The ex_cldr 2.17.2 release is about 5 years old so my advice would be to move to the current version. You shouldn't find any breaking changes in the API (as best I am aware).

Can you clarify what Elixir and OTP versions you are using? OTP in particular had a few issues in versions around 24 and 25.

If you truly can't upgrade for some reason, then manually download the locale files (after checking out the v2.17.2 tag) and put them in your locale directory. Thats typically deps/ex_cldr/priv/cldr/locales. But really, upgrading would be by far the better solution.

I seem to recall there were issues with both Erlang SSL module, certificate stores and an issue with CA trust chains but I can't recall the details right now. You might find this thread useful.

If you are also downloading locales manually then yes, the master branch was renamed to main years ago. And of your scripts which refer to the URL directly should be updated to use main branch. However note that GitHub will automatically redirect to main branch is you use master so thats unlikely to be the source of your issue. It really does look like a network connection issue.

[nate-river123]

@kipcole9 Doesn't look like a network issue (as it has been happening continuously since yesterday on both local and prod Kube envs), and it has never happened before.

The Elixir version we use is 1.11.2, since we do not have support for upper versions, we can't update to latest, as it requires Elixir 1.12

Could you suggest me which version should I upgrade ex_cldr to.

Current setup is like this

  ex_cldr 2.17.2
  ex_cldr_calendars 1.10.1
  ex_cldr_currencies 2.7.0
  ex_cldr_dates_times 2.4.0
  ex_cldr_numbers 2.13.2

[kipcole9]

Doesn't look like a network issue

I didn't suggest I thought it was a network issue. I said the message indicates it's an SSL/TLS issue. Since ex_cldr hasn't changed on your side - and since it works correctly on my system without error - the issue most likely lies elsewhere. And the error message you provided points directly at an SSL issue, Has your infrastructure team updated an OS version? CA versions?

You suggested this is an issue with "master" branch being deleted. You haven't provided anything to suggest that has anything to do with the issue you're seeing. Do you have more information? I don't see anything that suggests there's an issue with git branches.

Test app compiles and downloads correctly

I just built a test app with:

• Elixir 1.11.2
• OTP 24.1 and OTP 23.2.2
• ex_cldr 2.17.2

And it built and downloaded the locales with no issue:

% mix compile --force
Compiling 1 file (.ex)

04:33:47.668 [info]  Downloaded locale "de"

04:33:47.780 [info]  Downloaded locale "fr"
Generating T1 for 4 locales named ["de", "en", "fr", "root"] with a default locale named "en"
Generated t1 app

Further debugging

You can do some further debugging in an iex session by manually downloading a locale:

% iex -S mix
Erlang/OTP 23 [erts-11.1.6] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [hipe]

Interactive Elixir (1.11.2) - press Ctrl+C to exit (type h() ENTER for help)
iex> Cldr.Install.install_locale_name "ja", %Cldr.Config{locales: :all}

04:43:50.382 [info]  Downloaded locale "ja"
{:ok, "cldr/locales/ja.json"}

As you can see, that downloaded without error on Elixir 1.11.2, OTP 23.

[kipcole9]

One more thing you can try: add :castore or :certifi to your deps. They implement more up-to-date CA Stores than the native OTP ones. Then mix deps.compile ex_cldr --force.

[kipcole9]

Any further progress or info from your side?

[nate-river123]

@kipcole9
We were successfully able to build by using the following versions.

{:ex_cldr, "2.37.5"},
{:ex_cldr_numbers, "2.32.4"},
{:ex_cldr_dates_times, "2.16.0"},
{:ex_cldr_calendars, "1.22.0", override: true},
{:cldr_utils, "2.21.0", override: true}

Thank you for the quick support on this :)