fix(tui): add fallback exit handler for routes without dedicated exit handling#21066
fix(tui): add fallback exit handler for routes without dedicated exit handling#21066YumaKakuya wants to merge 2 commits intoanomalyco:devfrom
Conversation
… handling Plugin routes registered via api.route.register() do not have their own app_exit keyboard handler. Since exitOnCtrlC is disabled globally, and the three existing handlers (dialog, session, selection) all skip plugin routes, users get trapped with no way to exit. Rather than checking for a specific route type, this adds an app-level fallback that fires for any route whose type is not "home" or "session" (both of which already handle app_exit in their own components). This means future route types also get exit coverage automatically. Closes anomalyco#20069
|
The following comment was made by an LLM, it may be inaccurate: Potential Duplicate Found:
This PR directly addresses the same issue as PR #21066. According to the description, PR #20515 implements a similar fix but specifically checks for Recommendation: Check if PR #20515 is already merged or open. If it's open, coordinate with that PR's author or consider if one approach is preferable to the other. |
|
Aware of #20515 — both fix the same root cause. The key difference is in how the guard works:
Happy to close this if maintainers prefer the other approach, but wanted to offer the alternative since #20515 has been open for a few days with failing e2e checks. |
Issue for this PR
Closes #20069
Type of change
What does this PR do?
Plugin routes registered via
api.route.register()don't have their ownapp_exitkeyboard handler. SinceexitOnCtrlCis disabled globally, and theexisting handlers (dialog, session, selection) all skip plugin routes, users
get trapped with no way to exit except killing the process.
This adds an app-level fallback in
app.tsxthat fires for any route type thatisn't
homeorsession(both of which already handleapp_exitin their owncomponents). This way future route types also get exit coverage automatically,
rather than needing to be added to an allowlist.
See also #20515, which addresses the same issue but checks for
route === "plugin"specifically. This approach uses a negative guard instead so it doesn't need
updating when new route types are introduced.
How did you verify your code works?
Screenshots / recordings
N/A — keyboard behavior, no visual change.
Checklist