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 1041 27

2025-04-23 09:09:02 UTC

Showing Posts 1 to 10

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

D4no0

Here is the place in code where this error is raised: otp/lib/dialyzer/src/dialyzer_cplt.erl at 53ffb6a1363180ec67c36e3baa9745ee73e7b5a3 · erlang/otp · GitHub

I cannot figure out though what the code tries to accomplish, it seems there is some kind of file tracking involved.

Does this happen after invalidating the cache?

Post #1

paulanthonywilson

I did link to that in my question

I am about to invalidate the cache. It definitely doesn not happen locally.

[edit s/no/not/]

Post #2

D4no0

NVM, my bad, I’ve noticed only the mail listing link.

My assumption is that the PLT format is somehow versioned and you upgraded dialyzer version along the way. I would say that if invalidating the cache fixes the situation, then this issue falls most probably on some weird initial setup.

Post #3

paulanthonywilson

Yeah, the link was pretty subtle. It looks like the PLT is an erlang record, stored as a binary term which contains a version and an MD5 hash and if hash does not agree with a recomputed hash then it is an old plt. I don’t get it. ¯\(°_o)/¯

Post #4

paulanthonywilson

Still not solved, but I have not spent a ton of time trying to dig into the Erlang dialyzer code. Some more context though.

This is not a single plt file becoming somehow corrupt. Azure Pipelines being Azure Pipelines, caching is isolated to a specific branch. This error was occurring across multiple PR builds. Also the main build, which uses a different cache key, also got the error. Each PLT became old on the 7th of Jan.

As mentioned we’re using dialyxir . Briefly looking at the output it checks that the plt is up to date before running dialyzer with checking disabled .

So the output looks like

Checking PLT...
[(redacted the list of applications), ...]
PLT is up to date!
ignore_warnings: dialyzer.ignore_warnings

Starting Dialyzer
[
  check_plt: false,
  init_plt: '(redacted)/priv/plts/application.plt',
  files: [(redacted the list of files)],
  warnings: [:unknown]
]
:dialyzer.run error: Old PLT file (redacted)/priv/plts/application.plt

Also I have checked and at that time:

there was no change to any dependencies
no change to the dialyzer config
no change to Elixir and Erlang versions

Even if there were, I don’t see how it could have affected multiple pipelines given the cache isolation.

Post #5

D4no0

Did invalidating of cache help?

Post #6

paulanthonywilson

Yes, thanks. Building and caching a new plt worked.

Post #7

RobertoSchneiders

We have the same issue in a project using Elixir 1.18.3 and GitHub Actions. It has been happening for quite a while now. It seems completely random. Once this error appears, I have to clear the cache to fix it.

This is how I’m saving the PLT cache, I’m wondering if there is something else that should be considered for the cache key.

      - name: Save PLT cache
        id: plt_cache_save
        uses: actions/cache/save@v4
        if: steps.plt_cache.outputs.cache-hit != 'true'
        with:
          key: |
            plt-${{ runner.os }}-${{ matrix.otp }}-${{ matrix.elixir }}-${{ hashFiles('**/mix.lock') }}
          path: |
            priv/plts

Post #8

D4no0

That is generally not a really great strategy for caching, as you will have new caches only when your dependencies change.

I would say to use runner-id or whatever it is called to update your cache after each pipeline run, this will ensure that you are up-to-date when it comes to source files change. This will speed up your pipelines substantially.

Another point is that immutable cache is one of the worst systems I’ve encountered yet, so to be on the safe side in case the cache inevitably breaks, keep a prefix for your cache that can be manually changed such as v1-. If you have the option of removing old cache that is even better.

I think that if I’ll have to interact with GA again, I will do the cardinal sin and use JS to write a mutable caching action that works just as in gitlab . Worked with that one in production for many years and it’s vastly superior in every aspect.

Post #9

RobertoSchneiders

Can you elaborate on the use of the runner ID? I’m under the impression the runner ID will be different for every run in GA (at least for GitHub-hosted runners). Are you suggesting I update PLT’s cache after each run even if no dependencies changed?

I’m currently using the suggested GitHub Actions from Dialyxir

Post #10

Load more posts (17 remaining)