flake-update-cascade: update paths come from the pre-pull lock, so a stale checkout reports 'already up to date' without examining its current inputs #175

New issue

Closed

opened 2026-09-08 22:36:26 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-09-08 22:36:26 +01:00

Contributor

flake-update-cascade decides which input paths to update from each repository's flake.lock as it stands before the tool's own git pull, so a checkout whose default branch is behind hands Nix paths from the old lock. When the pull changes the input graph, Nix warns that the paths match no input and does nothing, and the repository is reported already up to date although its current inputs were never examined.

Symptom

Dry run on a development VM over clones of the workspace repositories, one of them allod/nexus cloned at cd157da, before the commit that removed its vm input. The tool's pull fast-forwarded it to 65bafe4; the update paths had already been read from the old lock:

==> allod-nexus
  pulling...
From ssh://forge.anarch.diy:2222/allod/nexus
   cd157da..65bafe4  master     -> origin/master
Updating cd157da..65bafe4
Fast-forward
 ...
 flake.lock                       | 232 +------------
 flake.nix                        |  26 +-
 ...
  updating vm/agenix/home-manager vm/home-manager vm/nixpkgs-unstable (dry-run)...
warning: 'vm/agenix/home-manager' does not match any input of this flake
warning: 'vm/home-manager' does not match any input of this flake
warning: 'vm/nixpkgs-unstable' does not match any input of this flake
  already up to date

The lock after the pull has root inputs agenix, home-manager and nixpkgs and no vm node; none of the three was looked at.

Evidence

cmd/flake-update-cascade/main.go: preflight reads each lock and stores its UpdatePaths before anything is pulled, and execute pulls and then uses the stored paths. Observed with the head-resolving build from allod/tools#174, which classifies a path that no longer resolves as one for Nix to update; the released program passes the same stale paths to nix flake update and gets the same warnings. Nix 2.34.8.

`flake-update-cascade` decides which input paths to update from each repository's `flake.lock` as it stands before the tool's own `git pull`, so a checkout whose default branch is behind hands Nix paths from the old lock. When the pull changes the input graph, Nix warns that the paths match no input and does nothing, and the repository is reported `already up to date` although its current inputs were never examined. ### Symptom Dry run on a development VM over clones of the workspace repositories, one of them `allod/nexus` cloned at `cd157da`, before the commit that removed its `vm` input. The tool's pull fast-forwarded it to `65bafe4`; the update paths had already been read from the old lock: ``` ==> allod-nexus pulling... From ssh://forge.anarch.diy:2222/allod/nexus cd157da..65bafe4 master -> origin/master Updating cd157da..65bafe4 Fast-forward ... flake.lock | 232 +------------ flake.nix | 26 +- ... updating vm/agenix/home-manager vm/home-manager vm/nixpkgs-unstable (dry-run)... warning: 'vm/agenix/home-manager' does not match any input of this flake warning: 'vm/home-manager' does not match any input of this flake warning: 'vm/nixpkgs-unstable' does not match any input of this flake already up to date ``` The lock after the pull has root inputs `agenix`, `home-manager` and `nixpkgs` and no `vm` node; none of the three was looked at. ### Evidence `cmd/flake-update-cascade/main.go`: `preflight` reads each lock and stores its `UpdatePaths` before anything is pulled, and `execute` pulls and then uses the stored paths. Observed with the head-resolving build from allod/tools#174, which classifies a path that no longer resolves as one for Nix to update; the released program passes the same stale paths to `nix flake update` and gets the same warnings. Nix 2.34.8.