flake-update-cascade hangs on interactive extra-substituters prompt and can't be killed with Ctrl-C #143

New issue

Closed

opened 2026-08-18 22:16:18 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-08-18 22:16:18 +01:00

Contributor

Summary

flake-update-cascade blocks indefinitely when a repo's flake declares extra-substituters in nixConfig, and the block cannot be interrupted with Ctrl-C — only ^Z (job-control stop) escapes it.

Reproduction

Run the cascade over a repo whose flake.nix has nixConfig.extra-substituters (observed with a cashudevkit repo advertising https://cache.cashudevkit.org https://cashudevkit.cachix.org):

flake-update-cascade nixpkgs-unstable profiles

Output stalls at:

  updating nixpkgs-unstable...
do you want to allow configuration setting 'extra-substituters' to be set to '...' (y/N)?

Answering y does not reliably continue; Ctrl-C is ignored; only Ctrl-Z stops the job:

^C
^C^X^Z
[1]+  Stopped                    flake-update-cascade nixpkgs-unstable profiles

Root cause

Two stacked issues:

Interactive prompt in a non-interactive tool. Each nix flake update invocation (dry-run branch and both execute branches) runs without --accept-flake-config. When a nested flake declares extra-substituters, nix prompts (y/N)? and waits on the TTY.
timeout breaks Ctrl-C. The update runs as timeout 120 nix flake update .... timeout places nix in a separate process group, so the terminal's SIGINT (Ctrl-C) does not reach the nix process holding the prompt. Hence Ctrl-C is ignored and only SIGTSTP (Ctrl-Z) stops the job. The 120s timeout also never fires while blocked on stdin in practice, because the prompt keeps the pipeline alive.

Suggested fix

Pass --accept-flake-config (or set accept-flake-config = true / equivalent) on every nix flake update invocation so the tool runs non-interactively, consistent with its batch/cascade purpose.
Additionally consider timeout --foreground (or </dev/null) so a stuck child is still interruptible and the timeout can actually fire.

Impact

A single consuming repo with extra-substituters in nixConfig wedges the whole cascade, requiring ^Z and manual cleanup. No data was corrupted in the observed run (all work-tree repos clean afterward), but the run aborts mid-cascade.

## Summary `flake-update-cascade` blocks indefinitely when a repo's flake declares `extra-substituters` in `nixConfig`, and the block cannot be interrupted with Ctrl-C — only `^Z` (job-control stop) escapes it. ## Reproduction Run the cascade over a repo whose `flake.nix` has `nixConfig.extra-substituters` (observed with a cashudevkit repo advertising `https://cache.cashudevkit.org https://cashudevkit.cachix.org`): ``` flake-update-cascade nixpkgs-unstable profiles ``` Output stalls at: ``` updating nixpkgs-unstable... do you want to allow configuration setting 'extra-substituters' to be set to '...' (y/N)? ``` Answering `y` does not reliably continue; Ctrl-C is ignored; only Ctrl-Z stops the job: ``` ^C ^C^X^Z [1]+ Stopped flake-update-cascade nixpkgs-unstable profiles ``` ## Root cause Two stacked issues: 1. **Interactive prompt in a non-interactive tool.** Each `nix flake update` invocation (dry-run branch and both execute branches) runs without `--accept-flake-config`. When a nested flake declares `extra-substituters`, nix prompts `(y/N)?` and waits on the TTY. 2. **`timeout` breaks Ctrl-C.** The update runs as `timeout 120 nix flake update ...`. `timeout` places nix in a separate process group, so the terminal's SIGINT (Ctrl-C) does not reach the nix process holding the prompt. Hence Ctrl-C is ignored and only SIGTSTP (Ctrl-Z) stops the job. The 120s timeout also never fires while blocked on stdin in practice, because the prompt keeps the pipeline alive. ## Suggested fix - Pass `--accept-flake-config` (or set `accept-flake-config = true` / equivalent) on every `nix flake update` invocation so the tool runs non-interactively, consistent with its batch/cascade purpose. - Additionally consider `timeout --foreground` (or `</dev/null`) so a stuck child is still interruptible and the timeout can actually fire. ## Impact A single consuming repo with `extra-substituters` in `nixConfig` wedges the whole cascade, requiring `^Z` and manual cleanup. No data was corrupted in the observed run (all work-tree repos clean afterward), but the run aborts mid-cascade.