| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2026-08-14 | utils: T9185: revert the proposed fix ask_yes_no() busy-looping forever on ↵ | Viacheslav Hletenko | |
| non-tty stdin | |||
| 2026-08-13 | utils: T9185: ask_yes_no() fails fast on non-tty instead of silent default | Ruben Herold | |
| jestabro (and dmbaturin previously, on #5362) pointed out that silently returning `default` on a non-TTY stdin still violates ask_yes_no()'s interactive-only contract, even though it stops the CPU-spin. Per T9185, sageframe's original incident confirms why: a caller that forgets an explicit non-interactive guard gets no error and no visible hang, just a process quietly pegging a core for days. Raise EOFError immediately instead, so a missing guard fails loudly and fast rather than either spinning or silently succeeding. Existing callers that are meant to run non-interactively already check no_prompt/-y before calling this (config_mgmt.py, backend.py) and are unaffected. | |||
| 2026-08-09 | utils: T9185: fix ask_yes_no() busy-looping forever on non-tty stdin | Ruben Herold | |
| commit-confirm (and ~40 other call sites) hang and burn a full CPU core indefinitely when invoked with stdin that isn't a TTY, e.g. a non-interactive vbash session (vbash -c "... commit-confirm 10; exit"). input() raises EOFError immediately and repeatedly in that case, and the except handler in ask_yes_no() looped straight back to input() with no backoff or exit condition. Check stdin.isatty() up front and return the default immediately when it's not a TTY, matching what a user pressing Enter (accepting the default) would already do interactively. | |||
