fix: retain shell errors and offer built-in debug recovery

[nklmilojevic]

When s fails in a container without sh, sofka now keeps the failure in a scrollable dialog. The command exit status and the last 16 KiB of standard error remain available until dismissal.

For a runtime error that identifies a missing shell, d opens the existing debug image prompt for the original pod and container. Creation requires acceptance and obeys read-only mode and debug guardrails, including typed confirmation. Canceling the prompt returns to the original error. Other failures do not offer missing-shell recovery.

Closes #606.

Agreed discussion: #604 (comment)

If debug creation fails, the original error remains available with the recovery error. The recovery command carries that error explicitly, so unrelated commands cannot inherit the old target. After the direct command exits, capture drains available stderr before honoring the 100 ms deadline for an idle pipe. A 1 MiB drain limit also bounds descendants that keep writing. These changes address Greptile's review findings.

Validation: just check and the final commit hooks passed with RUST_TEST_THREADS=1. Tests cover error retention, target selection, cancellation, guardrails, and terminal restoration after failure or an inherited stderr pipe, ready output at an expired deadline, continuous writers, and unrelated command failures. just fmt-check passed after the hooks. A parallel run exposed an existing port-allocation test failure; that test passed alone and in the serial suite. No live-cluster test was run.

[greptile-apps]

Greptile Summary

sofka now keeps failed shell commands visible and lets users recover missing shells with the built-in debug flow. It captures useful error output, restores the terminal promptly, and keeps recovery subject to read-only mode and debug guardrails.

• Failed commands retain their status and recent stderr in a scrollable dialog.
• Missing-shell failures can reopen the debug image flow for the original container.
• Recovery keeps the original error when canceled or blocked by guardrails.

Confidence Score: 5/5

The PR appears safe to merge. No new issue remains in the changed recovery or stderr paths.

The latest changes bind recovery errors to Suspend::Recovery and bound stderr reads after command exit. The three older threads are manually resolved.

Important Files Changed

Filename	Overview
src/terminal.rs	Captures stderr, keeps its last 16 KiB, and bounds reads after the direct command exits.
src/app/command_failure.rs	Shows command failures and offers debug recovery only for recognized missing-shell errors.
src/app/actions.rs	Keeps the original pod and container through the debug prompt and guardrails.
src/main.rs	Runs normal and recovery commands, then sends each result to the right error path.
src/terminal/tests.rs	Covers ready, idle, and nonstop stderr writers after command exit.

Sequence Diagram

sequenceDiagram
    actor User
    participant App
    participant Terminal
    participant Command
    User->>App: Press s
    App->>Terminal: Suspend TUI and run shell
    Terminal->>Command: Start kubectl exec
    Command-->>Terminal: stderr and exit status
    Terminal->>Terminal: Keep last 16 KiB
    Terminal-->>App: Restore TUI and return result
    alt command failed
        App-->>User: Show scrollable error
        alt missing sh and user presses d
            App-->>User: Ask for debug image
            App->>App: Check read-only mode and guardrails
            App-->>User: Ask for required confirmation
            User->>App: Accept
            App->>Terminal: Run kubectl debug
            Terminal-->>App: Return debug result
            alt debug failed
                App-->>User: Show original and recovery errors
            else debug succeeded
                App-->>User: Clear error
            end
        end
    else command succeeded
        App-->>User: Show completion message
    end

Loading

_{Reviews (3): Last reviewed commit: "fix: drain ready errors and bind recover..." | Re-trigger Greptile}