TuiApp.requestExit now reports the requested exit code even when dispose()
throws: disposal and the notification are both attempted, the code reaches the
exit sink unchanged, and the first failure is rethrown afterwards. That fixed
the hang, but it left a policy question open.
A run whose cleanup failed currently reports the code the application asked
for, usually 0. A supervising process therefore sees a clean exit after the
terminal may have been left in a modified state.
The options, none of which this repository has chosen yet:
- Keep reporting the requested code. Cleanup failure is the application's
problem, and the rethrown error is how it learns.
- Report a distinct non-zero code when cleanup failed, so a shell or CI can
see it without parsing output.
- Let the application decide, through an argument or a callback.
Whichever way it goes, the behavior belongs in TuiApp.exit's documentation
and in a test. Drive mode observes the same sink, so the decision also changes
what a driving host sees.
TuiApp.requestExitnow reports the requested exit code even whendispose()throws: disposal and the notification are both attempted, the code reaches the
exit sink unchanged, and the first failure is rethrown afterwards. That fixed
the hang, but it left a policy question open.
A run whose cleanup failed currently reports the code the application asked
for, usually
0. A supervising process therefore sees a clean exit after theterminal may have been left in a modified state.
The options, none of which this repository has chosen yet:
problem, and the rethrown error is how it learns.
see it without parsing output.
Whichever way it goes, the behavior belongs in
TuiApp.exit's documentationand in a test. Drive mode observes the same sink, so the decision also changes
what a driving host sees.