Hex v0.20.2-5 eats all memory and dies, but maybe it is us

[jsm]

This post is a copy of the github issue I’ve just created to report a bug, but maybe it is us after all because it doesn’t occur with every project. Then it is not a bug but we do need help

Since the release of hex v0.20.2, we have a problem with one - but not all - of our projects. It’s an umbrella with 5 apps. When we try to execute mix.deps.get , the terminal hangs at Resolving Hex dependencies... . The process then starts to eat all available memory and swap, until (apparently) the kernel has had enough and kills it. I’ve tried this on a machine with 32GB of ram and it happily eats all of it. This issue occurs in- and out of Docker containers with multiple Elixir versions, both alpine- and debian based. The issue does not occur with hex v0.20.1 or lower.

When the process is killed, there’s some additional output (screenshot from GitLab build):

… which is weird, because it sure as hell uses a lot more than 24MB.

To demonstrate the bug, I’ve put together a repo with our mix files: https://github.com/juulSme/hex-0.20.2-to-5-bug. Cloning and running docker build . will cause the issue. Adapting the Dockerfile to use hex v0.20.1 solves it. Maybe the problem is in our mix files somewhere, because we don’t experience it with all of our projects.

[jsm]

Update: I’ve narrowed down the issue a bit further. I’ve removed some dependencies and some umbrella apps. There’s 2 apps left down from 5, my_app and my_app_endpoint that apparently cause the issue together. They don’t share any dependencies except for gettext ~> 0.14.

[bottlenecked]

Not a hex expert here but could it be a circular dependency problem? Project A depends on B which depends on C which depends back to A

[outlog]

somehow {:ecto, “~> 3.0.9”}, is the culprit in combination with
{:guardian_db, “~> 2.0”},

definitely a bug - can be resolved by doing {:ecto, “~> 3.0”},

can you further minimise and file a github issue?

[jsm]

How on earth did you find that out? I will try that as soon as I have time, which may not be until next week but thanks for your help!

[outlog]

bit of luck perhaps…

went in to each app and did mix.deps.get - the my_app is the culprit…

looked at mix.exs for the failing app and noticed an apparent mismatch with guardian_db at 2.0 and guardian at 1.2 (It’s NOT a mismatch)

commented out guardian_db and mix deps.get now worked…

uncommented guardian_db and now I got proper warning related to ecto not resolving as it’s locked to 3.0.9…

[jsm]

It seems your solution works. Mind blown Thanks!