[ISSUE #1160]🔥Optimize ValidateTopicResult String with CheetahString#1161
[ISSUE #1160]🔥Optimize ValidateTopicResult String with CheetahString#1161TeslaRustor merged 1 commit intomainfrom
Conversation
|
🚀Thanks for your contribution🎉. CodeRabbit(AI) will review your code first🔥 |
WalkthroughThe pull request introduces changes to the Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1161 +/- ##
==========================================
+ Coverage 16.50% 16.69% +0.18%
==========================================
Files 427 427
Lines 52640 52695 +55
==========================================
+ Hits 8690 8798 +108
+ Misses 43950 43897 -53 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
rocketmq-common/src/common/topic.rs (2)
101-129: Consider moving error messages to module-level constantsThe validation logic is well-optimized with CheetahString. However, the error messages could be moved to module-level constants for better reusability and maintenance.
Consider refactoring like this:
+ const BLANK_TOPIC_ERROR: &str = "The specified topic is blank."; + const ILLEGAL_CHARS_ERROR: &str = "The specified topic contains illegal characters, allowing only ^[%|a-zA-Z0-9_-]+$"; pub fn validate_topic(topic: &str) -> ValidateTopicResult { if topic.trim().is_empty() { - const REMARK: &str = "The specified topic is blank."; return ValidateTopicResult { valid: false, - remark: CheetahString::from_static_str(REMARK), + remark: CheetahString::from_static_str(BLANK_TOPIC_ERROR), }; } if Self::is_topic_or_group_illegal(topic) { - const REMARK: &str = "The specified topic contains illegal characters, allowing only ^[%|a-zA-Z0-9_-]+$"; return ValidateTopicResult { valid: false, - remark: CheetahString::from_static_str(REMARK), + remark: CheetahString::from_static_str(ILLEGAL_CHARS_ERROR), }; }
173-175: Add test coverage for set_remark methodThe set_remark method is currently not covered by tests according to the code coverage report.
Would you like me to help generate a test case for the set_remark method? Here's a suggested test:
#[test] fn test_set_remark() { let mut result = ValidateTopicResult { valid: true, remark: CheetahString::empty(), }; let new_remark = CheetahString::from_static_str("test remark"); result.set_remark(new_remark.clone()); assert_eq!(result.remark(), &new_remark); }🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 173-173: rocketmq-common/src/common/topic.rs#L173
Added line #L173 was not covered by testsrocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs (2)
90-90: Add test coverage for topic validation error pathsThe static analysis indicates that the error paths for invalid topics are not covered by tests. These are critical paths that handle validation failures and should be tested.
Would you like me to help create unit tests for these scenarios? The tests should cover:
- Invalid topic validation cases
- System topic conflicts
- Mixed message type validation
Example test structure:
#[test] fn test_update_and_create_topic_validation_failures() { // Test invalid topic // Test system topic conflict // Test mixed message type }Also applies to: 216-216
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 90-90: rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs#L90
Added line #L90 was not covered by tests
89-91: Improve error handling consistencyThe error handling patterns vary across different methods. Consider standardizing the approach:
- Use constants for common error messages
- Consistent formatting style for error messages
- Structured error types for different validation failures
Consider creating an error module:
mod errors { pub const SYSTEM_TOPIC_CONFLICT: &str = "The topic[{}] is conflict with system topic."; pub const TOPIC_NOT_EXIST: &str = "The topic[{}] not exist."; // Add more error constants }This would improve maintainability and ensure consistency across error messages.
Also applies to: 215-217, 326-330, 402-406, 495-499, 583-587
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 90-90: rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs#L90
Added line #L90 was not covered by tests
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs(2 hunks)rocketmq-common/src/common/topic.rs(3 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs
[warning] 90-90: rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs#L90
Added line #L90 was not covered by tests
[warning] 216-216: rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs#L216
Added line #L216 was not covered by tests
rocketmq-common/src/common/topic.rs
[warning] 173-173: rocketmq-common/src/common/topic.rs#L173
Added line #L173 was not covered by tests
🔇 Additional comments (4)
rocketmq-common/src/common/topic.rs (3)
21-21: LGTM: CheetahString import aligns with optimization goals
The addition of CheetahString is consistent with the PR's objective to optimize string handling in ValidateTopicResult.
159-175: LGTM: Consistent type changes for CheetahString optimization
The ValidateTopicResult struct and its methods have been properly updated to use CheetahString.
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 173-173: rocketmq-common/src/common/topic.rs#L173
Added line #L173 was not covered by tests
178-260: LGTM: Comprehensive test coverage
The test module provides excellent coverage with:
- Positive and negative test cases
- Validation of error messages
- System topic handling
- Not-allowed topic scenarios
rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs (1)
90-90: String cloning approach needs verification
The changes introduce explicit cloning of the remark string using result.remark().clone(). While this ensures ownership of the string for the response, we should verify if this is the most efficient approach.
Let's check if there are any existing patterns for handling remarks in responses:
Also applies to: 216-216
✅ Verification successful
Based on the search results, I can now provide a definitive response about the string cloning approach:
String cloning is consistent with codebase patterns
The set_remark implementation in rocketmq-remoting/src/protocol/remoting_command.rs accepts impl Into<CheetahString>, which is the optimized way to handle strings in this codebase. The current approach of using result.remark().clone() is correct as it provides the owned string that can be converted into CheetahString.
Looking at other usages across the codebase:
- Direct string literals:
.set_remark("some message") - Formatted strings:
.set_remark(format!("...")) - Cloned strings:
.set_remark(result.remark().clone())
All these patterns are valid as they provide owned strings that can be converted into CheetahString.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check existing patterns for handling remarks in responses
# Look for other usages of set_remark to understand the common pattern
# Search for set_remark usage patterns
rg -A 2 'set_remark\('
# Search for ValidateTopicResult usage
ast-grep --pattern 'let result = TopicValidator::validate_topic($$$)'
Length of output: 23997
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 90-90: rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs#L90
Added line #L90 was not covered by tests
| .set_code(ResponseCode::SystemError) | ||
| .set_remark(result.remark()), | ||
| .set_remark(result.remark().clone()), | ||
| ); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Extract common topic validation logic
There's duplicated validation logic across different methods. Consider extracting these checks into a dedicated validation method:
impl TopicRequestHandler {
fn validate_topic_request(&self, topic: &str) -> Result<(), RemotingCommand> {
let result = TopicValidator::validate_topic(topic);
if !result.valid() {
return Err(RemotingCommand::create_response_command()
.set_code(ResponseCode::SystemError)
.set_remark(result.remark().clone()));
}
if self.inner.broker_config.validate_system_topic_when_update_topic
&& TopicValidator::is_system_topic(topic)
{
return Err(RemotingCommand::create_response_command()
.set_code(ResponseCode::SystemError)
.set_remark(format!(
"The topic[{}] is conflict with system topic.",
topic
)));
}
Ok(())
}
}This would:
- Reduce code duplication
- Centralize validation logic
- Make it easier to maintain and modify validation rules
Also applies to: 215-217, 326-330
🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 90-90: rocketmq-broker/src/processor/admin_broker_processor/topic_request_handler.rs#L90
Added line #L90 was not covered by tests
Which Issue(s) This PR Fixes(Closes)
Fixes #1160
Brief Description
How Did You Test This Change?
Summary by CodeRabbit
New Features
CheetahString.Bug Fixes
remarkfield in response commands for invalid topics.Tests