Lockfile is "unstable"

[NobbZ]

Describe the bug

In one of my configurations I have the following behaviour for a couple of days now:

I do a nix flake update --commit-lock-file and I get a lockfile that feels correct. On the next operation that I do on the flake, the lockfile gets rewritten and some transitive inputs are locked to a path in my store.

Using the tagged release 2.4 does not have the bug. I do only observe this with a recent master CLI (I have not "downgraded" the demon, only the CLI for testing old version behavior)

Steps To Reproduce

1. Use a recent nix from master
2. git clone my repository from https://github.com/nobbz/nixos-config
3. Switch to branch overhaul
4. do a nix flake update --commit-lock-file
5. Lockfile is fine
6. Do nix flake metadata

See that now the lockfile gets updated before the metadata is shown.

Expected behavior

Lockfile isn't touched

nix-env --version output

$ nix-env --version
nix-env (Nix) 2.5pre20211117_480c883

Additional context

I consciously observed this behaviour about 3 days ago.

[nixos-discourse]

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

https://discourse.nixos.org/t/how-to-fix-a-nar-hash-mismatch/16594/16

[NobbZ]

This still happens with nix (Nix) 2.6.0pre20211214_18e4851.

To summarize what I wrote in the linking discourse thread:

My assumption is, that this is related to me pinning nixpkgs through the local registry and the fact that one dependency does use "implicit" inputs (no inputs section but nixpkgs argument to outputs function).

My (current) pins (regarding nixpkgs):

$ ❯ nix registry list | grep nixpkgs
system flake:nixpkgs path:/nix/store/swl04xiyn1a153n5lbaak903fysp6p0f-source?lastModified=1639347265&narHash=sha256-q5feWoC64+h6T6J89o2HJJ8DOnB%2f4vwMODBlZIgeIlA=&rev=b0bf5f888d377dd2f36d90340df6dc9f035aaada
system flake:nixpkgs2105 path:/nix/store/b5lfk2rblxqkp918k9y5qmdvkzf2cwk8-source?lastModified=1639130158&narHash=sha256-%2f5a%2f7J3AE5ATzB3HdFZ9C9VlPbUK5bIGsRX7veSujXA=&rev=3b422991781220853035dbe353ba8b7cb279b6b3
system flake:nixpkgs2111 path:/nix/store/g5bl53zqkkc6pcr6izsbrhcs1fjkxdhd-source?lastModified=1639161226&narHash=sha256-75Y08ynJDTq6HHGIF+8IADBJSVip0UyWQH7jqSFnRR8=&rev=573095944e7c1d58d30fc679c81af63668b54056
global flake:nixpkgs github:NixOS/nixpkgs/nixpkgs-unstable

(The first entry is actually what the flake.lock always gets changed to, if it doesn't already point to something in the store!)

[Enzime]

I've been observing the same issue so I wrote a git bisect script to figure out what caused this:

#!/usr/bin/env bash
# shellcheck shell=bash
set -x

FLAKE_DIR=~/misc/nixos-config
SHOULD_NOT_EXIST="nixpkgs_6"

nix build . || exit 125

if [[ -f $FLAKE_DIR/flake.lock ]]; then
  rm $FLAKE_DIR/flake.lock || exit 125
fi

env -u GIT_DIR nix run . -- flake metadata $FLAKE_DIR --json || exit 125

env -u GIT_DIR nix run . -- flake metadata $FLAKE_DIR --json | jq -e ".locks.nodes.\"$SHOULD_NOT_EXIST\""

EXIT_CODE=$?

if [[ $EXIT_CODE -eq 0 ]]; then
  exit 1
else
  exit 0
fi

07bffe7 is the first bad commit
commit 07bffe7
Author: Alexander Bantyev balsoft@balsoft.ru
Date: Wed Nov 10 14:56:22 2021 +0300

Flakes: refetch the input when a follows disappears

When an input follows disappears, we can't just reuse the old lock
file entries since we may be missing some required ones. Refetch the
input when this happens.

Closes https://github.com/NixOS/nix/issues/5289

src/libexpr/flake/flake.cc | 14 ++++++++++++++
tests/flakes.sh | 28 +++++++++++++++++++++++++---
2 files changed, 39 insertions(+), 3 deletions(-)

From #5518 to fix #5289