Dialyzer error: Old PLT file

paulanthonywilson

I’m working with a team that are running (relatively) old versions of Elixir and Erlang. Last month I added dialyzer, via dialyxir (can never spell that) to their build. Today we are running into an issue:

:dialyzer.run error: Old PLT file /apps/[redacted]/priv/plts/application.plt

The build is on Azure. The PLTs are cached using Azure Pipeline caching (here if you want to know but I wouldn’t if I could avoid it).

Dialyxir config is

  defp dialyzer do
    [
      plt_add_apps: [:mix, :ex_insights],
      plt_file: {:no_warn, "priv/plts/application.plt"},
      ignore_warnings: "dialyzer.ignore_warnings"
    ]
  end

The plts are excluded from source control.

Versions:

elixir 1.14.2-otp-25
erlang 25.3.2.6

I know I can fix the issue by invalidating the cache but I would like to understand how it happened in the first place. The only thing I’ve been able to find is this somewhat cryptic Erlang mailing list q&a. Old PLT file? .

The checking is going on here which looks like there is some discrepancy between an internally held hash in the PLT and the file contents.

Thoughts?

27 comments

#dialyzer

0 1630 27

2025-04-23 09:09:02 UTC

Showing Posts 27 to 18

Show Best Posts
Show All (oldest first)
Show All (newest first)

paulanthonywilson

Sorry, I was kidding. Good look with wading through the job swamp!

We were also not pinning the exact erlang version and seem to have just hit the issue again when an updated image was used from Docker. It’s good to have an explanation.

Post #27

dimitarvp

Hey, at least for the moment I have an excuse: I’m deep into the job search swamp.

Later on, why not. It’s one of those things that should have been nailed and written in stone like 5 years ago.

Post #26

paulanthonywilson

yeah, someone should do that . Stares pointedly

Wouldn’t help the OP (me) who is in the unfortunate situation of building on Azure.

Post #25

dimitarvp

All of this thread really makes me want somebody open-sources an exact and very detailed CI/CD setup(s) for Elixir projects that work perfectly on GitHub, GitLab, BitBucket, any Forgejo hosting etc.

It seems to annoying to do every time.

Post #24

RobertoSchneiders

awesome! You were right, we were not pinning the patch version in CI. I followed your suggestions.

Thank you!

Post #23

lud

Hey! I just updated my Github config

I use this strategy on my personal projects: nvir/.github/workflows/elixir.yaml at main · lud/nvir · GitHub

It’s based on the well-known template but I removed the check on cache hit for the PLT, as I got problems with that. And it’s simpler. Also checking the PLT is actually fast, even for large projects.

If you add 200 files I’m not sure how slow it is but that’s why I added a cache_vsn variable that I can bump. But I too use dependabot so the mix.lock file is updated quite often.

I wonder if in addition to hashFiles it is possible to use something like find lib test -type f | wc -l in the cache keys, that would make dialyzer update when files are added. But at some point you will never use the cache if you invalidate it for everychange.

So I prefer the current strategy of hashing mix.lock and just regenerate the PLT for the app code only. Also I feel like Github action got really faster lately.

Post #22

alexslade

@RobertoSchneiders We recently fixed this issue too.

Perhaps you have the same cause: are you not pinning the patch version of erlang in your CI?

Here is the cause breakdown from our bug ticket:

Dialyzer creates an md5 hash of files to check, and that includes beam files.

We are not pinning an exact version of erlang in CI

Prior to each failing PLT check has been an erlang patch version bump!

It looks like erlang project releases the patch bumps roughly weekly. This explains the roughly-weekly occurences we were seeing. It wasn’t a timestamp issues as first suspected.

This patch bump means that the PLT files are different to the ones in the cache, so dialyzer is correctly flagging the old PLT files.

Proposed solution: check .tool-versions during CI setup and install the exact pinned version of erlang that our project uses.

Note: I also included the erlang version in the cache key, to avoid confusion in future and to immediately bust the cache lookup.

Post #21

RobertoSchneiders

Understood. We update dependencies with Dependabot every week, so that’s not a big issue for us but I will keep an eye on it, thank you.

Post #20

dimitarvp

That’s not happening because again, the virtual instances where the actions are ran are often using network-mounted disks. They don’t even have local disks.

Post #19

D4no0

I think the effort would be better spent on making a mutable local-first cache system, otherwise all of these solutions are just a hack around the main problem.

If only these goddamn action weren’t written in JS… also BTW you cannot write tests for them, amazing.

Post #18

Load more posts (17 remaining)