feat: stream handler added - #24
Conversation
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a new ChangesStreaming Handler Module
Possibly related PRs
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/stream/handler.rs (1)
189-195: ⚡ Quick winAdd config validation before accepting custom handler settings.
jitter_factoris documented as0.0..=1.0, butwith_configaccepts anyf64(including NaN/out-of-range). Similarly, zero durations/delays can slip in. A lightweightvalidate()on configs (called fromwith_config) will prevent invalid runtime states as execution logic is added.Also applies to: 572-577
🤖 Prompt for 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. In `@src/stream/handler.rs` around lines 189 - 195, Add a lightweight validate() method on the handler config struct(s) that checks jitter_factor is finite and within 0.0..=1.0, that any Duration/timeout/delay fields are non-zero and finite, and returns a Result/Err with a clear message on invalid values; call this validate() from with_config (and the other with_config-like constructor referenced around the other struct) before accepting the settings so with_config rejects NaN/out-of-range jitter_factor and zero/invalid durations. Ensure the validation references the exact fields (jitter_factor and the duration/delay fields) and propagate the error instead of silently accepting the bad config.
🤖 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 `@src/stream/handler.rs`:
- Around line 1-28: The module-level rustdoc overstates behavior (saying
StreamHandler performs retry/timeout/fallback/cancellation) while the file
currently only exposes config/data types and constructors; update the docs to
accurately reflect the current implementation by changing claims about runtime
behavior to say the file defines the StreamHandler type, its configuration
structs, and constructors (and note which behaviors are planned or implemented
elsewhere), or alternatively implement the missing behavior in the referenced
functions (init_with_retry, process_events, fallback_non_streaming) to match the
doc; ensure references to ApiClient::stream_messages, ApiClient::create_message,
and CancelSignal are consistent with what is implemented and apply the same doc
corrections to the later summary section currently duplicated around the end of
the file.
---
Nitpick comments:
In `@src/stream/handler.rs`:
- Around line 189-195: Add a lightweight validate() method on the handler config
struct(s) that checks jitter_factor is finite and within 0.0..=1.0, that any
Duration/timeout/delay fields are non-zero and finite, and returns a Result/Err
with a clear message on invalid values; call this validate() from with_config
(and the other with_config-like constructor referenced around the other struct)
before accepting the settings so with_config rejects NaN/out-of-range
jitter_factor and zero/invalid durations. Ensure the validation references the
exact fields (jitter_factor and the duration/delay fields) and propagate the
error instead of silently accepting the bad config.
🪄 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 Plus
Run ID: 1badbb3e-3b73-4d78-97d5-d44823a0f1f4
📒 Files selected for processing (2)
src/stream.rssrc/stream/handler.rs
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/stream/handler.rs (1)
665-670: ⚡ Quick winConstructor currently permits invalid configs to enter
StreamHandler.
with_configstores inputs directly, so validation is opt-in and easy to skip. Adding a fallible constructor (try_with_config) would enforce invariants at the API boundary.Suggested API addition
impl StreamHandler { + pub fn try_with_config( + timeout: StreamTimeoutConfig, + retry: StreamRetryConfig, + ) -> Result<Self, String> { + timeout.validate()?; + retry.validate()?; + Ok(Self { + timeout_config: timeout, + retry_config: retry, + }) + } + #[must_use] pub fn with_config(timeout: StreamTimeoutConfig, retry: StreamRetryConfig) -> Self { Self { timeout_config: timeout, retry_config: retry, } } }🤖 Prompt for 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. In `@src/stream/handler.rs` around lines 665 - 670, Add a fallible constructor try_with_config on StreamHandler that enforces config invariants rather than storing inputs blindly: implement StreamHandler::try_with_config(timeout: StreamTimeoutConfig, retry: StreamRetryConfig) -> Result<Self, StreamConfigError> which validates both timeout and retry (call existing validate methods if present, or add validate() on StreamTimeoutConfig/StreamRetryConfig) and returns Err with a descriptive StreamConfigError if any check fails; on success return the StreamHandler with timeout_config and retry_config set. Ensure the new StreamConfigError type (or use an existing error enum) carries which config failed and why so callers can handle validation failures at the API boundary.
🤖 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 `@src/stream/handler.rs`:
- Around line 169-188: StreamTimeoutConfig::validate currently misses a guard
for max_consecutive_timeouts allowing 0; add a check in the validate() method to
return Err when self.max_consecutive_timeouts.is_zero() (or == 0) with a clear
message like "max_consecutive_timeouts must be non-zero" and place it alongside
the other zero-value guards (e.g., after the progress_interval check or
logically near the other timeout field checks) so the config enforces at least
one consecutive timeout.
---
Nitpick comments:
In `@src/stream/handler.rs`:
- Around line 665-670: Add a fallible constructor try_with_config on
StreamHandler that enforces config invariants rather than storing inputs
blindly: implement StreamHandler::try_with_config(timeout: StreamTimeoutConfig,
retry: StreamRetryConfig) -> Result<Self, StreamConfigError> which validates
both timeout and retry (call existing validate methods if present, or add
validate() on StreamTimeoutConfig/StreamRetryConfig) and returns Err with a
descriptive StreamConfigError if any check fails; on success return the
StreamHandler with timeout_config and retry_config set. Ensure the new
StreamConfigError type (or use an existing error enum) carries which config
failed and why so callers can handle validation failures at the API boundary.
🪄 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 Plus
Run ID: e71783b7-af64-4d06-a341-3dfb0d2e290f
📒 Files selected for processing (1)
src/stream/handler.rs
77262a6 to
356d5e5
Compare
added basic skeleton for stream handler with configs