Escape Key Strikes Again

Back in May I fixed the Ballpark Genius CLI’s escape key so it stopped quitting the whole program while you were mid-sentence in the suggestion dropdown. Turns out that wasn’t the last escape-key bug in this CLI, just the first one I’d found.

/import runs asynchronously, you can keep typing other commands while it streams progress in the background. Press Escape during one, though, and screen.key('escape')‘s fallback handler didn’t know or care that an import was running. It called this.exit(0) unconditionally, tore down the blessed screen, and killed the Node process, taking whatever import was mid-flight down with it. No confirmation, no warning, just gone.

Same fix shape as last time, a guard before the unconditional exit, except this one needed actual state to check against. When isImporting is true, Escape now opens a confirm sub-prompt, “An import is still running. Exit anyway? (yes/no)”, the same isInSubPrompt pattern the CLI already uses for restore and delete confirmations. Only an explicit yes gets you out. Anything else cancels and the import keeps running. Escape behaves exactly like it did before this fix when nothing’s importing.

Two bugs, four months apart, same root cause pattern: a key handler written for the CLI’s simplest state, escape as a blunt instrument, that never got revisited once the CLI grew actual async operations worth protecting. Folks, I’d bet there’s a third one somewhere. There’s always a third one, and I digress into predicting my own future bugs a little too easily these days.