feat(minimald): implement scaffolding for execution over ssh - #281
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughAdds a new exec module implementing async subprocess spawn/bridge, validates and dispatches SSH exec requests (using MINIMAL_SESSION_ID_ENV), wires exec handling into the connection code, centralizes the env constant, and adds unit and end-to-end tests plus a TestClient::exec helper. ChangesSSH Exec Request Implementation
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/minimald/src/exec.rs`:
- Around line 167-173: The code currently calls unwrap() on w.flush().await,
e.flush().await, ws.eof().await, ws.exit_status(...).await and ws.close().await
after drop(r), which will panic if the SSH channel is broken; change these to
handle errors gracefully instead of panicking — for each call in exec.rs replace
the unwraps with non-panicking handling (e.g., match/if let Err(err) = ... {
log/warn the error with context using the task logger or tracing, and ignore or
recover as appropriate) or use let _ = ... to explicitly discard errors where
safe; ensure you keep drop(r) and still attempt eof/exit_status/close but
tolerate and log failures for ws.eof, ws.exit_status, ws.close and for
w.flush/e.flush so the task does not crash on broken channels.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 37dd2c51-243c-4c80-ab26-4ea7def8a9a9
📒 Files selected for processing (5)
crates/minimald/src/connection.rscrates/minimald/src/exec.rscrates/minimald/src/lib.rscrates/minimald/src/sftp.rscrates/minimald/src/test_harness.rs
101342e to
1a0fd52
Compare
| /// Resolves when the process exits. `Ok(None)` means the process | ||
| /// was terminated by a signal rather than exiting with a numeric | ||
| /// code. | ||
| async fn wait(&mut self) -> io::Result<Option<i32>>; |
There was a problem hiding this comment.
Would there be any reason we might want to capture the specific signal?
There was a problem hiding this comment.
Yes, on one side we need to communicate the exit status down the ssh channel, but also, every process needs to be wait()’ed on to avoid zombie processes.
The main piece is the new
ExecTaskstruct, which represents and async task & encapsulates the logic gluing a process to an ssh channel.ExecTaskis generic over aSpawnabletrait, which is something that can build a process (in the future, this can also be sandboxed processes ala minimal tasks).For now I've just got it running unsandboxed processes as a simple way to test - we won't be doing this long term.
I'm also thinking in the long term
ExecTaskcan probably be an actor, and recieve messages to do things like kill its process etc. And we could have the closure inspawn()register theExecTaskwith a session and/or connection.Summary by CodeRabbit
New Features
Tests