When running dune build or dune tools exec ocamllsp, sometimes dune decides to rebuild all the package dependencies, which obviously takes ages (and might prevent you from working if the network is not currently available).

For concrete examples, yesterday I had dune tools exec ocamllsp running, C-c, reran it, and it rebuilt all the dependencies. Doing it again seems to cache properly that time.
Just now, I was wondering why dune build was taking 30s+ to do a null build in a minuscule repo (which was in fact a null build, there was some crazy levenshtein_distance calls while reading the lock directory, which I still need to figure out). Once the first build stopped, or maybe I stopped it, I reran dune build with profiling, same thing. I then grabbed the latest dune preview build, reran dune build, and it rebuilt all the dependencies??
And I've seen multiple times in the past as well, where nothing relevant should have changed but dune decided to rebuild everything.

I don't know if that's enough to understand what's happening. Maybe dune doesn't like being C-c, but that'd be silly since that's the only way to stop a polling build.
I think dune should write down why it's taking these decisions, since they are so costly. I don't know if it already does with --trace, but if it does, then I claim this should be output by default: it's too late to set a debug flag after the problem has happened.

$ dune --version
"Dune Developer Preview: build 2025-08-20T02:28:50Z, git revision
24ca148234aa4eab93dff79573ed47e79f9d7694"

On Ubuntu 24.04.3 LTS