While RunAsync is running, Ctrl+C and SIGTERM can never end a hung app: every signal is cancelled, however many are sent

[matt-edmondson]

What's wrong

UIApplication.RunAsync registers an interrupt handler for the whole run (TUI/Services/UIApplication.cs:145) and disposes it only in finally (:176). ConsoleInterruptSource.OnSignal (TUI/Services/ConsoleInterruptSource.cs:40-46) cancels the runtime's default termination on every signal: Ctrl+C sets e.Cancel = true, and SIGTERM sets context.Cancel = true. It then only calls Shutdown(), which cancels a token. That token is observed only by the input loop, between keys.

So if the app's own code hangs, nothing will ever act on that token. That covers an OnHandleInput or a render that deadlocks or loops, and a synchronous wait inside a handler. Every further Ctrl+C or kill <pid> is cancelled as well. The only ways out are kill -9 or closing the terminal. Before #110/#117, the runtime's default behaviour ended such a process.

Reproduction (main 95d9508, real process and real signals)

The root is a StackPanel subclass whose OnHandleInput does Thread.Sleep(Timeout.Infinite). The provider's ReadInputAsync returns a key immediately. With await app.RunAsync() running, send three signals of each kind, 1 s apart:

SIGINT  x3: process STILL ALIVE   (needed kill -9)
SIGTERM x3: process STILL ALIVE   (needed kill -9)

Control: the same hanging handler called outside RunAsync exits after a single SIGINT or SIGTERM.

Why it matters

A bug in application code becomes a process that can't be interrupted. It also defeats supervisors that expect SIGTERM to end the process, such as systemd, docker stop and CI timeouts. Those only escalate to SIGKILL after a grace period.

Suggested fix / acceptance criteria

• Cancel only the first signal of a run and turn it into a graceful Shutdown().
• If a second Ctrl+C or SIGTERM arrives while shutdown is still pending, don't cancel it, so the runtime terminates the process. Alternatively, restore the terminal and call Environment.Exit.
• Optionally, force the exit after a grace timeout that starts at the first signal.
• Add a unit test through OnSignal / FakeInterruptSource: the first signal cancels and calls onInterrupt, and a second signal is not cancelled.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. Any hang in application code (handler, render, sync wait) makes a TUI app immune to Ctrl+C and SIGTERM for the whole run, so users must kill -9 or close the terminal, and systemd / docker stop / CI timeouts have to wait out their grace period. No data loss, but it's a regression from the runtime default (Ctrl+C bypasses the app's exit path, leaving the terminal cursor hidden after the process terminates #110/fix: exit through the normal shutdown path on Ctrl+C [patch] #117) and it affects every app built on the library.
• Area / suggested assignment: TUI/Services/ConsoleInterruptSource.cs:40-46 (OnSignal cancels unconditionally) and :57-91 (Registration wires Ctrl+C and SIGTERM to it); TUI/Services/UIApplication.cs:143-145 (registration for the whole run), :171-182 (dispose in finally), :188-196 (OnInterrupt -> Shutdown, which only cancels the token).
• Related: RunAsync leaves a Console.ReadKey pending after shutdown, so the next keypress (in the host or in a second RunAsync) is swallowed #149 (a ReadKey left pending after shutdown) is also about shutdown not completing cleanly, but it's a separate fix. Cross-repo: Console mode skips OnStop on SIGHUP (terminal closed, SSH dropped), and on Ctrl+C/SIGTERM that arrives while OnStart is still running TrayApp#30 and Bump the microsoft group with 3 updates #21 hook the same two signals (CancelKeyPress + PosixSignalRegistration SIGTERM, always Cancel = true). In TrayApp's ConsoleRunner.Run the SIGTERM registration also stays live while OnStop runs, so a hung OnStop there can't be SIGTERMed either. Whatever "first signal is graceful, second is fatal" pattern lands here is worth reusing there.
• In progress? No open PR matches. fix: invalidate each ancestor once instead of 2^depth times #181 and fix: keep indentation and spacing when TextElement wraps words #182 cover unrelated rendering fixes.
• Notes: Keep a per-registration int _signalled and use Interlocked.Exchange in OnSignal (or pass the state in). Only the first signal calls cancelDefaultTermination() and onInterrupt(). Later signals return without cancelling, so the runtime terminates the process. To restore the cursor on the forced path, the second signal could call a best-effort restore callback and then Environment.Exit(130). An optional grace timer started on the first signal could do the same. Tests: call OnSignal twice on one registration state and assert the first cancels and calls onInterrupt, and the second does neither. Also add a FakeInterruptSource test that RunAsync still shuts down gracefully on one signal.

---

Generated by Claude Code