Local path repository suddenly has a hash mismatch after GC

[viraptor]

Describe the bug

I've been running nix develop on a package while trying to get it built. To clean up some space from temporary builds I've run nix store gc. This somehow broke the expected nix hashes.

Steps To Reproduce

I don't know if that's reproducible, but my actions were:

1. Create a flake with local nixpkgs checkout:

{
  description = "foo";

  inputs = {
    nixpkgs.url = "path:/Users/viraptor/src/nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
  };
  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem
      (system:
        let pkgs = nixpkgs.legacyPackages.${system}; in
        {
          devShell = import ./shell.nix { inherit pkgs; };
        }
      );
}

2. nix develop - works as expected
3. nix store gc
4. nix develop - gives:

error: NAR hash mismatch in input 'path:/Users/viraptor/src/nixpkgs?narHash=sha256-Cl79qBCjCZjmqRB8gZwRPu6gd5Y8w5YmMNMRjBLODas=' (/nix/store/5zax5bf87k99ag40p2s3kk5r9rgqbsvq-source), expected 'sha256-Cl79qBCjCZjmqRB8gZwRPu6gd5Y8w5YmMNMRjBLODas=', got 'sha256-6p9KNgnvuD/+u64TKoM1rf2a07dNoHXp7aL0cPJZWGA='

       … while realising the context of a path

       at «string»:20:19:

           19|
           20|           flake = import (sourceInfo + (if subdir != "" then "/" else "") + subdir + "/flake.nix");
             |                   ^
           21|

       … while evaluating anonymous lambda

       at «string»:10:13:

            9|     builtins.mapAttrs
           10|       (key: node:
             |             ^
           11|         let

       … from call site

       … while evaluating anonymous lambda

       at «string»:23:25:

           22|           inputs = builtins.mapAttrs
           23|             (inputName: inputSpec: allNodes.${resolveInput inputSpec})
             |                         ^
           24|             (node.inputs or {});

       … from call site

       … while evaluating anonymous lambda

       at /nix/store/i4flq9lpia5b55ik7zc834rbhdk27mvs-source/shell.nix:1:1:

            1| { pkgs ? import <nixpkgs> { } }:
             | ^
            2| with pkgs;

       … from call site

       at /nix/store/i4flq9lpia5b55ik7zc834rbhdk27mvs-source/flake.nix:14:22:

           13|         {
           14|           devShell = import ./shell.nix { inherit pkgs; };
             |                      ^
           15|         }

       … while evaluating the attribute 'devShell'

       at /nix/store/i4flq9lpia5b55ik7zc834rbhdk27mvs-source/flake.nix:14:11:

           13|         {
           14|           devShell = import ./shell.nix { inherit pkgs; };
             |           ^
           15|         }

Expected behavior

Pre and post gc the system should behave the same.

nix-env --version output

nix-env (Nix) 2.6.0

[colemickens]

This can happen when you:

• update the source for a package, but forget to update the hash
• Nix accidentally lets you think you were building the updated pkg, even though you were still using the old cached source
• GC runs and cleans up that source package with the real hash value
• Nix will now re-acquire that source code package and notice that you gave it the wrong hash

that's at least one way you can wind up here. Beyond that. the implications get a lot more serious if there's something else going on.

[viraptor]

Turns out that removing flake.lock allowed a rebuild, but it is a very confusing experience. /Users/viraptor/src/nixpkgs has not changed between both develop calls.

[samvv]

I'm experiencing the same issue here. I kind of expect this workflow, as described by @colemickens, to just work while developing a package. The best example would probably be writing and testing the flake.nix itself.

Removing flake.lock did not fix the issue for me.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/going-crazy-on-flake-with-systemd-service/51488/1