Internal error in InstallPlan.completed

[mrkkrp]

Describe the bug

Internal error in InstallPlan.completed occurs without a clear reason or indication what went wrong.

To Reproduce

Happens on CI, here:

https://travis-ci.org/mrkkrp/zip/jobs/619365152

Only with GHC 8.6.5. I believe it started to happen relatively recently (*), so maybe a new version of some dependency was published and it breaks something in an unexpected way, but why would it fail with such an informative error message?

(*) I tried to re-run older builds that used to succeed and now they also fail, and also only for GHC 8.6.5.

Expected behavior

Ideally the build should succeed. If there is a genuine problem, a helpful error message should be displayed.

System information
Whatever Travis CI uses. Cabal version is 3.0.

[phadej]

Hmm. I cannot reproduce this locally, yet internal error is definitely not good enough diagnostic.

EDIT: cannot reproduce with 1.2.0 nor master or zip, nor on my machine nor inside docker container with nothing else than cabal-install-3.0 and ghc-8.6.5. Looks hardly reproducible, except that it is :( I don't know, my best guess is to improve the internalError message, and see if it's reproducible with another cabal binary.

[phadej]

4d09392f1f cabal-install/Distribution/Client/InstallPlan.hs (Duncan Coutts      2016-07-22 17:05:43 +0100 649)     asReadyPackage (Configured pkg) = ReadyPackage pkg
b97578f863 cabal-install/Distribution/Client/InstallPlan.hs (Duncan Coutts      2016-10-21 16:08:01 +0100 650)     asReadyPackage _ = internalError "completed" ""

cabal/cabal-install/Distribution/Client/InstallPlan.hs

Lines 649 to 650 in 53eddce

	asReadyPackage (Configured pkg) = ReadyPackage pkg
	asReadyPackage _ = internalError "completed" ""

I don't know what's the variant violated there is, and why it might be violated. @dcoutts ideas?

[phadej]

I was able to reproduce this, see #6439, which will at least slightly improve the situation. I'm not sure what breaks the store in the first place. Repairing it shouldn't be difficult, when we figure out solution to #6437

[phadej]

To fix CI, clean up CI caches. That should fix the issue, if it doesn't please report, then I'll need to take a closer look.

Hopefully we get the above patch released soon, so one could investigate closer what is broken in the store.

[phadej]

cleaning up caches did work. I'm closing this issue, this is a duplicate of #4119

[phadej]

For the record, to reproduce this kind of error

1. pick package which depends on hspec-discover or cpphs as built-tool-depends
2. build normally
3. remove the library directory (not the executable) from the cabal store
4. try to build again

You'll get something like

% /opt/cabal/3.0/bin/cabal build -w ghc-8.0.2 servant:spec
Build profile: -w ghc-8.0.2 -O0
In order, the following will be built (use -v for more details):
 - hspec-discover-2.7.1 (lib) (requires build)
internal error in InstallPlan.completed: not in configured state: Installed hspec-discover-2.7.1-ff2d68841b7634d566bc5fd02477586dd4155b13b4aeede45d021359aac220cb
CallStack (from HasCallStack):

[mouse07410]

@phadej I'm getting a similar error trying to build https://github.com/haskell/haskell-language-server (details are in haskell/haskell-language-server#194).

You showed how to reproduce this error (which I managed without any help or guidance ;). How can I remedy this error? Cleaning up what caches in my installation, and how? I hope the answer is not "wipe out your ~/.cabal/ and re-install whatever you still need".

[mouse07410]

@mouse07410 unassigned @dcoutts 1 minute ago

Say what...?!

[phadej]

@mouse07410 GitHub has extensive keyboard shortcuts, https://docs.github.com/en/github/getting-started-with-github/keyboard-shortcuts#issue-and-pull-request-lists

[jneira]

You showed how to reproduce this error (which I managed without any help or guidance ;). How can I remedy this error? Cleaning up what caches in my installation, and how? I hope the answer is not "wipe out your ~/.cabal/ and re-install whatever you still need".

@mouse07410 Another less invasive workaround could be to delete manually all the offending packages from the store dir and run cabal-store-check --repair. You can install the utility cabal-store-check from https://github.com/phadej/cabal-extras

[mouse07410]

cabal-store-check sounds great.

What’s a good way to figure if a package is “offending”? Just start with those that the install attempt complains about? And what’s the best way to delete them - is there a command, or should I go manually through all the ~/.cabal subdirectories and rm everything that seems related to that package name?

[mouse07410]

Just tried installing cabal-store-check, and it fails the same way. Apparently, the store is broken badly enough.

All my builds are dynamic. What subdirectories from this do I need to completely wipe?

$ ll ~/.cabal
total 112
drwxr-xr-x@  16 ur20980  MITLL\Domain Users    512 Jul  3 18:30 ./
drwxr-xr-x@ 758 ur20980  MITLL\Domain Users  24256 Jul 12 16:27 ../
-rw-r--r--@   1 ur20980  MITLL\Domain Users   6148 Mar 28  2019 .DS_Store
drwxr-xr-x   49 ur20980  MITLL\Domain Users   1568 Jul  8 18:57 bin/
-rw-r--r--    1 ur20980  MITLL\Domain Users   5554 Jun 22 16:54 config
-rw-r--r--    1 ur20980  MITLL\Domain Users   4737 Mar 15 17:07 config-orig
-rw-r--r--    1 ur20980  MITLL\Domain Users   5648 Apr  3 11:09 config.backup
drwxr-xr-x    3 ur20980  MITLL\Domain Users     96 Jun 23 22:08 lib/
drwxr-xr-x    6 ur20980  MITLL\Domain Users    192 Jul  8 22:22 logs/
drwxr-xr-x    5 ur20980  MITLL\Domain Users    160 Apr  1 11:22 packages/
drwxr-xr-x    4 ur20980  MITLL\Domain Users    128 Apr 11 21:18 share/
-rw-r--r--    1 ur20980  MITLL\Domain Users   5706 Jul  3 18:30 skete-config
-rw-r--r--    1 ur20980  MITLL\Domain Users   5574 May  1 21:33 static-config
drwxr-xr-x    4 ur20980  MITLL\Domain Users    128 Jun 23 22:08 store/
-rw-r--r--    1 ur20980  MITLL\Domain Users    699 Jun 12  2018 where-is-my-stuff.txt
-rw-r--r--    1 ur20980  MITLL\Domain Users     25 May  1 21:19 world

And I assume I'll need to rebuild every cabal-installed executable in ~/.cabal/bin/ (as they're all dynamic)?

$ du -sh ~/.cabal
 14G	/Users/ur20980/.cabal
$ 

Update

run cabal-store-check --repair

Apparently, it doesn't work on Mac at all. --repair nukes the ~/.cabal/lib/ directory, with predictable consequences: phadej/cabal-extras#30