recover(E3): tools CLI worktree — byteport-cli crate from stash-1#249
recover(E3): tools CLI worktree — byteport-cli crate from stash-1#249KooshaPari wants to merge 1 commit into
Conversation
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
CodeAnt AI is reviewing your PR. |
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
Bot
added
the
size:L
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| println!("{}", String::from_utf8_lossy(&encoded)); | ||
| } | ||
| CodecAction::Decode { hex } => { | ||
| let decoded = codec.decode(hex.as_bytes()).expect("decode should succeed"); |
There was a problem hiding this comment.
Suggestion: This will panic on invalid user input because hex decoding errors are handled with expect; WireCodecAdapter::decode returns an error for odd-length or non-hex input, so the CLI crashes instead of returning a normal user-facing failure. Handle the Result and print an error with a non-zero exit code instead of panicking. [logic error]
Severity Level: Major ⚠️
- ❌ `byteport-cli codec decode` crashes on invalid hex input.
- ⚠️ Hinders use of CLI for malformed payload debugging.Steps of Reproduction ✅
1. Run the CLI with an invalid hex string, e.g. `byteport-cli codec decode abc`, which
Clap wires to `Command::Codec::Decode` and `run_codec` in
`crates/byteport-cli/src/main.rs:104-119`.
2. In `run_codec` at `main.rs:121-135`, the `CodecAction::Decode { hex }` branch is
selected and calls `codec.decode(hex.as_bytes())` where `hex` is the user-supplied string.
3. `WireCodecAdapter::decode` in `crates/byteport-transport/src/ports/codec.rs:89-103`
checks the input length and characters; for odd-length input (`"abc"`) or non-hex
characters (`"zz"`) it returns `Err(io::ErrorKind::InvalidData, ...)` instead of `Ok`.
4. Back in `run_codec` at `main.rs:131`, `.expect("decode should succeed")` is called on
this `Err`, causing a panic and process abort (exit code 101 and a backtrace), instead of
printing a user-friendly error and exiting with a controlled non-zero status.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/byteport-cli/src/main.rs
**Line:** 131:131
**Comment:**
*Logic Error: This will panic on invalid user input because hex decoding errors are handled with `expect`; `WireCodecAdapter::decode` returns an error for odd-length or non-hex input, so the CLI crashes instead of returning a normal user-facing failure. Handle the `Result` and print an error with a non-zero exit code instead of panicking.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| let sent = transport.send(data.as_bytes()).expect("send"); | ||
| println!("Sent {sent} bytes"); | ||
| let echoed = transport.take_tx(); | ||
| println!("Echo (tx buffer): {}", String::from_utf8_lossy(&echoed)); |
There was a problem hiding this comment.
Suggestion: The transport ping flow claims to connect/send/receive, but it never calls recv; it only dumps the local TX buffer, which is just what was sent. This means the receive path of the transport abstraction is not exercised and the CLI output is misleading about an actual round-trip. [incomplete implementation]
Severity Level: Major ⚠️
- ⚠️ `transport ping` shows tx buffer, not real echo.
- ⚠️ Receive path of `WireTransportAdapter` untested via CLI.Steps of Reproduction ✅
1. Run `byteport-cli transport ping` (optionally with `--data hello`); Clap maps this to
`TransportAction::Ping { data }` defined at `crates/byteport-cli/src/main.rs:76-84` and
dispatches to `run_transport` via `main.rs:104-119`.
2. In `run_transport` at `main.rs:137-148`, a `WireTransportAdapter::new()` is created and
`connect("memory://pipe")` is called; `WireTransportAdapter::connect` at
`crates/byteport-transport/src/ports/transport.rs:115-119` simply marks the adapter as
connected and stores the peer address.
3. The `TransportAction::Ping` arm at `main.rs:141-146` calls
`transport.send(data.as_bytes()).expect("send")`; `WireTransportAdapter::send` at
`transport.rs:127-136` appends the bytes into the internal `tx` buffer and returns the
length, which is printed as `"Sent {sent} bytes"`.
4. Immediately after, `run_transport` calls `let echoed = transport.take_tx();` and prints
`"Echo (tx buffer): ..."` at `main.rs:144-145`; `WireTransportAdapter::take_tx` at
`transport.rs:103-111` just drains and returns the local `tx` buffer; no data is ever
pushed into `rx` or read via `recv`, so despite the docstring "Connect, send, and
receive…" at `main.rs:78` the receive path and any true round-trip are never exercised and
the "echo" is simply the locally-sent bytes.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/byteport-cli/src/main.rs
**Line:** 142:145
**Comment:**
*Incomplete Implementation: The transport ping flow claims to connect/send/receive, but it never calls `recv`; it only dumps the local TX buffer, which is just what was sent. This means the receive path of the transport abstraction is not exercised and the CLI output is misleading about an actual round-trip.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| let ui = MockUiAdapter::new(); | ||
| match ui.prompt(&msg) { | ||
| Ok(resp) => println!("Prompt response: {resp:?}"), | ||
| Err(e) => { | ||
| println!("Prompt result: {e} (cancelled expected for mock)") | ||
| } | ||
| } |
There was a problem hiding this comment.
Suggestion: The prompt command is wired to MockUiAdapter::new() with no queued responses, and that adapter returns Err(UserCancelled) when empty, so this branch can never produce a successful prompt response at runtime. Use an interactive adapter for CLI prompts or seed mock responses before calling prompt. [incomplete implementation]
Severity Level: Major ⚠️
- ❌ `ui prompt` subcommand never returns successful prompt response.
- ⚠️ Cannot exercise `UiPort` happy-path from CLI tool.Steps of Reproduction ✅
1. Invoke the UI prompt subcommand, e.g. `byteport-cli ui prompt info \"Title\" \"Body\"`,
which Clap maps to `UiAction::Prompt { kind, title, body }` and routes into `run_ui` in
`crates/byteport-cli/src/main.rs:104-119`.
2. In `run_ui` at `main.rs:150-188`, the `UiAction::Prompt` arm matches and constructs a
`PromptMessage` based on `kind`, e.g. `PromptMessage::info(title, body)` as implemented in
`crates/byteport-transport/src/ports/ui.rs:63-67`.
3. `run_ui` then creates `let ui = MockUiAdapter::new();` at `main.rs:179`;
`MockUiAdapter::new()`/`Default` in `crates/byteport-transport/src/ports/ui.rs:178-192`
sets `responses` to an empty `VecDeque` and no `with_response`/`with_responses` helper is
called from the CLI.
4. When `ui.prompt(&msg)` executes, `MockUiAdapter`'s `UiPort` impl at `ui.rs:246-256`
pushes the message into `prompt_calls`, sees `invalid_state_for_prompts == false`, then
calls `pop_front()` on the empty `responses` queue and returns
`Err(UiError::UserCancelled)`, so the match in `main.rs:180-185` always enters the
`Err(e)` arm and prints `"Prompt result: user cancelled the operation (cancelled expected
for mock)"`; the `Ok(resp)` branch is unreachable and no successful `PromptResponse` is
ever produced.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/byteport-cli/src/main.rs
**Line:** 179:185
**Comment:**
*Incomplete Implementation: The prompt command is wired to `MockUiAdapter::new()` with no queued responses, and that adapter returns `Err(UserCancelled)` when empty, so this branch can never produce a successful prompt response at runtime. Use an interactive adapter for CLI prompts or seed mock responses before calling `prompt`.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
CodeAnt AI finished reviewing your PR. |
KooshaPari
force-pushed
the
recover/E3-tools-cli-worktree
branch
from
8c41ff9 to
3625a3c
Compare
💡 Codex ReviewLine 5 in 8c41ff9  Move workspace membership to an approved L2 task
BytePort/crates/byteport-cli/src/main.rs Lines 130 to 131 in 8c41ff9  Handle invalid hex without panicking
When a user passes an odd-length or non-hex payload to ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
Legacy Tooling Scan Report
No violations detected. This is a WARN-mode scan. Fix before strict enforcement begins. |
|
1 participant
User description
Summary
CodeAnt-AI Description
Add a BytePort command-line tool for codec, transport, UI, and upload workflows
What Changed
byteport-clicommand-line tool that can encode and decode hex text, run a simple transport ping, render named UI views, and create S3 upload instructionsImpact
✅ One terminal tool for common BytePort checks✅ Faster manual verification of codec and transport behavior✅ Clearer upload setup details💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.