feat: add non-interactive prism exec - #31
Conversation
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
codeant-ai
Bot
added
the
size:XXL
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| if hasOption(args[1:], "--help") || hasOption(args[1:], "-h") { | ||
| printExecHelp(stdout) | ||
| return nil | ||
| } |
There was a problem hiding this comment.
Suggestion: The dispatch scans for help flags before parseExecOptions, so any invocation containing --help or -h bypasses validation and exits successfully. For example, prism exec --api chat --help --unknown prints help instead of returning the documented usage error. Parse the arguments first, or only short-circuit for a standalone help invocation. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Malformed exec commands can exit successfully.
- ⚠️ CI scripts may skip expected usage-error handling.
- ⚠️ Unknown options are hidden by help output.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** internal/cli/run.go
**Line:** 77:80
**Comment:**
*Incorrect Condition Logic: The dispatch scans for help flags before `parseExecOptions`, so any invocation containing `--help` or `-h` bypasses validation and exits successfully. For example, `prism exec --api chat --help --unknown` prints help instead of returning the documented usage error. Parse the arguments first, or only short-circuit for a standalone help invocation.
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
| return inferenceHTTPError(response) | ||
| } | ||
|
|
||
| payload, err := readResponseIdle(ctx, response.Body, api.InferenceIdleTimeout) |
There was a problem hiding this comment.
Suggestion: stream-json does not actually stream output to stdout because the entire response is first accumulated by readResponseIdle and only then parsed and written. A long-lived SSE request therefore withholds already-received events until the server closes the connection, defeating the documented one-object-per-event behavior and causing unbounded memory usage for large streams. [api mismatch]
Severity Level: Critical 🚨
- ❌ stream-json consumers receive no incremental events.
- ⚠️ Long-running streams accumulate the entire response in memory.
- ❌ Large streams can exhaust the CLI process memory.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** internal/cli/exec.go
**Line:** 140:140
**Comment:**
*Api Mismatch: `stream-json` does not actually stream output to stdout because the entire response is first accumulated by `readResponseIdle` and only then parsed and written. A long-lived SSE request therefore withholds already-received events until the server closes the connection, defeating the documented one-object-per-event behavior and causing unbounded memory usage for large streams.
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| results <- result{data: chunk} | ||
| } | ||
| if err != nil { | ||
| results <- result{err: err} |
There was a problem hiding this comment.
Suggestion: The response reader goroutine can leak after cancellation or an idle timeout. If the result channel already contains one chunk, the goroutine can block forever sending the next chunk or its final error after the caller returns; closing the response body does not unblock that channel send. Use a cancellation-aware send or otherwise wait for the reader goroutine to terminate before returning. [resource leak]
Severity Level: Major ⚠️
- ⚠️ Interrupted SSE executions can leak reader goroutines.
- ⚠️ Repeated stream cancellations increase process resource usage.
- ❌ Long-running CLI automation can eventually become unstable.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** internal/cli/exec.go
**Line:** 372:375
**Comment:**
*Resource Leak: The response reader goroutine can leak after cancellation or an idle timeout. If the result channel already contains one chunk, the goroutine can block forever sending the next chunk or its final error after the caller returns; closing the response body does not unblock that channel send. Use a cancellation-aware send or otherwise wait for the reader goroutine to terminate before returning.
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
1 participant
Summary
Verification
Closes #30