Doesn't seem to be properly cache busting when cross project dependencies change. #6193
Comments
|
@erlandsona, I tried to reproduce this with a simpler example, but without success. My example was a two-package project ( resolver: lts-21.3
packages:
- packageB
- packageAand package B's name: packageB
version: 0.1.0.0
dependencies:
- base >= 4.7 && < 5
- packageA
executables:
packageB:
main: Main.hs
source-dirs: appIf I change a file in package A and build the package B component (extracts only): So, in my example, the change to file Can we narrow down what you are experiencing? What file in your |
|
We'll so I can show the log output without debug and maybe it'll be clearer. Issue isn't that stack doesn't show the change as detected and then hypothetically it recompiles packageB. It's that at runtime the previous version of packageA is still used. Not at my machine rn, but I can try to create a small repro tomorrow. Maybe try updating the string of a log statement in packageA then run packageB then update packageA again and see if the updates take effect. |
|
@erlandsona, your reference to behaviour at run time has confused me, as that behaviour will depend on what source code has been compiled into the running executable file. To more fully specify my simple example: package A's module LibA where
someFuncA :: IO ()
someFuncA = putStrLn "Message: A-1"and package B's executable is: module Main where
import LibA
main :: IO ()
main = someFuncAIf I change the message in the source code of |
|
Issue isn't that we're not recompiling the executable but that |
|
Okay! Got a working reproduction of the issue! |
|
When the log statement in common in changed the executable that I expect to have the latest log statement is still using a stale log. |
|
Between the "REPRO" commit and the one prior, the primary thing I added was a "3rd project". |
|
Okay new info from some more tinkering. I can get rid of the "issue" by removing the fan out. There's 2 paths to get to common and when common is changed but projectA is not, and because there's no direct reference to common in projectB for that functionality, I think stack is picking the longer path to common through projectA which hasn't changed therefor we end up with the stale reference. |
|
@erlandsona, I've cloned your example repository, but I still can't reproduce the problem. When I change common's EDIT: What output are you experiencing, when you do something similar? |
|
So coming back to this today... what's weird is I had it reproduced without the Couple other variables include:
In the following output, I expect "Common 2" to change to "Common 3" but notice in the 2nd output it still prints "Common 2". Bump to |
|
@erlandsona, that is indeed very odd (by the way, I've been testing on Windows; I'll switch to Ubuntu). When you bump the source, everything seems to get recompiled - as I would expect - but the final Can we take the The |
|
@erlandsona, good news, I can reproduce what you are experiencing on Windows and Ubuntu 22.04.1 LTS (WSL 2), and it does seem to be somehow connected with the |
|
Phew!!! Glad I'm not sending yah on a wild goose chase! |
|
I also tried you're suggestion with |
|
I've compared the corresponding output ( and
|
|
Not sure what |
|
Another test: but ... Something seems to be going wrong with the registration step when |
|
My current hypothesis is that this arises because - with I have been investigating with the simplest of packages: library-only, single module module Lib
( someFunc
) where
someFunc :: IO ()
someFunc = putStrLn "someFunc1"and inspecting the resulting With |
|
More experimentation, with the |
|
@erlandsona, I am now fairly certain that this is a feature/bug of GHC 9.4.5. It seems that GHC's 'recompilation checker' assumes that recompilation of a module is not required if the ABI hash of its imports has not changed, even if the import module's source code has changed - and that is more likely to happen with I'll follow up elsewhere to see if I can determine if this is a feature or a bug of GHC. |
|
I came across haskell/cabal#4381 and found it helpful to understand Cabal's use of 'installed package ID', which I could not find documentation for outside of https://cabal.readthedocs.io/en/stable/developing-packages.html#package-names-and-versions and "There is a separate installed package ID that uniquely identifies each installed package instance. Most of the time however, users need not be aware of this detail." |
|
@mpilgrem we're definitely keeping a close eye on the progress of that issue you mentioned and we'll give the Thanks for all your help with this! |
|
So we tried the Our current solution is to just put all the modules under a single package.yaml / library such that this bug doesn't surface. Of course this has the drawback that any external repo's depending on this project have to compile unnecessary modules in order to leverage "shared types". |
|
@erlandsona, there is now a related discussion at the Haskell Community. It appears that this may be a GHC bug, introduced in GHC 9.4.5 (or some other GHC 9.4 version). If you can use GHC 9.2.8, I think it may be free of the bug. |
|
There's also now a ghc bug: https://gitlab.haskell.org/ghc/ghc/-/issues/23724 Thanks @mpilgrem and @erlandsona for figuring this out. We just upgraded to GHC 9.4.5, and I thought I was losing my mind for a bit there 😂 |
Stack doesn't seem to be properly cache busting when cross project dependencies change.
Steps to reproduce
Example:
$project_root/stack.yaml
$project_root/common/package.yaml
$project_root/db/package.yaml
$project_root/web/package.yaml
Expected
When a change is made to common or db those changes buste the cache of web such that web is recompiled with the latest changes from it's dependencies.
Actual
web seems to be stuck recompiling with stale cached data such that changes in common / db aren't propagating properly.
If you suspect that a Stack command misbehaved, please include the output of
that command in
--verbosemode. If the output is larger than a page pleasepaste the output in a Gist.
Stack version
Method of installation
Platform
Your platform (machine architecture and operating system)
The text was updated successfully, but these errors were encountered: