feat(torii-core): specify namespaces to exclusively index #2687
Conversation
WalkthroughOhayo, sensei! This pull request introduces changes to the event processing configuration in the Torii application. Key modifications include the removal of optionality for the Changes
Possibly related PRs
Suggested reviewers
🪧 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
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
crates/torii/cli/src/args.rs (1)
285-285: Consider adding namespace format validation, sensei!The test demonstrates namespace patterns like "ns-E" and "ns-EH", but there's no validation to ensure consistent formatting. Consider adding validation to prevent potential issues.
+ // Add this validation in EventsOptions or where the historical field is processed + fn validate_namespace(ns: &str) -> bool { + // Adjust the regex pattern based on your naming convention + lazy_static! { + static ref NS_PATTERN: Regex = Regex::new(r"^[a-zA-Z]+-[a-zA-Z]+$").unwrap(); + } + NS_PATTERN.is_match(ns) + }crates/torii/cli/src/options.rs (1)
142-148: Ohayo! Consider enhancing the help text for namespacesThe help text could be more specific about the expected format of namespace strings to ensure users provide correct input.
#[arg( long = "indexing.namespaces", value_delimiter = ',', - help = "The namespaces of the world that torii should index. If empty, all namespaces will be indexed." + help = "Comma-separated list of world namespaces that torii should index (e.g., 'namespace1,namespace2'). If empty, all namespaces will be indexed." )]
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (4)
bin/torii/src/main.rs(1 hunks)crates/torii/cli/src/args.rs(2 hunks)crates/torii/cli/src/options.rs(3 hunks)crates/torii/core/src/processors/mod.rs(1 hunks)
🔇 Additional comments (5)
crates/torii/core/src/processors/mod.rs (2)
32-32: Ohayo! The new namespaces field looks good, sensei!
The addition of pub namespaces: HashSet<String> aligns well with the PR objective of specifying namespaces to exclusively index. The use of HashSet is appropriate for storing unique namespace identifiers.
Line range hint 52-61: Consider utilizing the config parameter in EventProcessor::process
Ohayo sensei! I notice that the _config parameter in the process method is prefixed with an underscore, indicating it's currently unused. Since we've added the new namespaces field, this parameter could be valuable for namespace-based filtering.
Let's check if any implementations are using this parameter:
Consider implementing namespace filtering logic using this parameter if appropriate for your use case.
bin/torii/src/main.rs (1)
147-148: Ohayo sensei! Please verify the safety of these changes and add documentation.
The changes to EventProcessorConfig initialization have two important aspects:
-
The removal of
unwrap_or_default()forhistorical_eventssuggests this is now a required field. Please ensure all callers are updated to handle this breaking change. -
The new
namespacesfield adds filtering capability but lacks documentation about its purpose and expected values.
Let's verify the impact of these changes:
Consider adding documentation to explain:
- The purpose and behavior of namespace filtering
- Expected format and values for namespaces
- Impact of an empty namespace collection
✅ Verification successful
Ohayo sensei! The changes are safe but need documentation love!
Based on the codebase analysis:
- The
historicalfield inEventsOptionsis already a non-optional vector (CLI arg with value_delimiter), so removingunwrap_or_default()is safe. - Both fields are properly documented in their source structs:
historical_eventshas clear documentation inoptions.rs- However,
namespacesinEventProcessorConfiglacks documentation
Please add documentation for the namespaces field in crates/torii/core/src/processors/mod.rs to explain:
/// A set of namespace identifiers to exclusively process events from.
/// Empty set means all namespaces are processed.
pub namespaces: HashSet<String>,🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential breaking changes and documentation
# Check if there are any callers still using the optional pattern
rg -A 2 "historical\?: Option<"
# Check if there's documentation for the new namespaces field
ast-grep --pattern 'struct EventProcessorConfig {
$$$
/// $DOC_COMMENT
namespaces: $TYPE
$$$
}'
Length of output: 139
Script:
#!/bin/bash
# Let's try a different approach to find the relevant structs and their usage
# Find EventsOptions struct definition
rg -A 10 "struct EventsOptions"
# Find EventProcessorConfig struct definition
rg -A 10 "struct EventProcessorConfig"
# Check for any documentation about namespaces in the codebase
rg -i "namespace.*filter" --type rust
# Look for historical events usage patterns
rg "historical_events" --type rust -A 2
Length of output: 2481
crates/torii/cli/src/args.rs (1)
239-239: Ohayo! Verify backward compatibility with existing configurations, sensei.
The change from Option<Vec<String>> to Vec<String> for historical events makes the field mandatory. While this aligns with the goal of explicit namespace specification, we should ensure existing configurations won't break.
✅ Verification successful
Ohayo! The change is safe and backward compatible, sensei!
The codebase analysis shows that:
historicalfield inEventsOptionshas a default empty vector implementation- The field is properly handled throughout the codebase in both GRPC and core implementations
- Existing configurations use explicit array syntax for historical events, making them compatible with the new non-optional type
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for existing torii config files in the codebase
fd -e toml -e json . | while read -r config_file; do
echo "Checking $config_file for historical events configuration:"
rg -A 2 'historical.*=' "$config_file"
done
Length of output: 36595
Script:
#!/bin/bash
# Let's check the implementation and usage of historical events in the codebase
# First, let's find the struct/type definition
rg -A 5 "struct.*Events" crates/torii
# Then check for historical events usage in tests and implementation
rg -A 5 "historical.*=|historical:" crates/torii
# Finally, check for any migration code or breaking changes
rg -B 5 "historical" crates/torii/cli/src/args.rs
Length of output: 15371
crates/torii/cli/src/options.rs (1)
180-180: Ohayo sensei! Breaking change alert for historical field
The change from Option<Vec<String>> to Vec<String> improves code clarity by removing unnecessary optionality. However, this is a breaking change that may affect existing configurations.
Let's check for any existing configurations that might be affected:
Also applies to: 185-185
✅ Verification successful
The initial search revealed a configuration file using historical_events. I'd like to verify the code usage and test configurations to better understand the impact of this breaking change before providing the final response.
Ohayo sensei! Breaking change confirmed but safely handled
The change from Option<Vec<String>> to Vec<String> is indeed a breaking change, but the codebase appears to handle it gracefully:
- The existing configuration in
bin/torii/torii.tomluseshistorical_events=[...]format which is compatible withVec<String> - The change is well-contained within the CLI configuration layer and doesn't propagate to the core functionality, as evidenced by the historical field usage across the codebase
- Test cases in
crates/torii/cli/src/args.rsalready expect non-optional vectors
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for existing usage of historical field in configurations
# Look for TOML/YAML/JSON config files that might use the historical field
rg -g '*.{toml,yaml,yml,json}' -B2 -A2 'historical.*='
Length of output: 248
Script:
#!/bin/bash
# Let's check the historical field usage in the code to understand the impact
ast-grep --pattern 'historical'
# Also check for any test configurations
fd -e rs -x rg -l 'historical'
Length of output: 4321
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (6)
crates/torii/core/src/processors/store_del_record.rs (1)
Line range hint
1-85: Consider adding tracing for ignored models, sensei! 📝While the implementation is solid, it might be helpful to add debug-level tracing when models are ignored due to namespace filtering. This would aid in debugging and monitoring.
Here's a suggested enhancement:
Err(e) => { if e.to_string().contains("no rows") { + tracing::debug!( + target: LOG_TARGET, + selector = %event.selector, + "Ignoring non-existent model due to namespace filtering" + ); return Ok(()); } return Err(e); }crates/torii/core/src/processors/store_set_record.rs (1)
55-57: Consider documenting the namespace filtering behavior, sensei! 📚Since this change is part of the namespace-specific indexing feature, it might be valuable to:
- Document this behavior in the processor's documentation
- Consider adding metrics/logging to track skipped records for monitoring
- Consider adding a debug log when skipping records to help with troubleshooting
crates/torii/core/src/processors/store_update_record.rs (1)
63-63: Consider more robust error type matching, sensei!The current approach of string matching on error messages (
contains("no rows")) is somewhat fragile. Consider either:
- Using a proper error type from your database layer that can be matched explicitly
- Creating a custom error type for namespace filtering scenarios
Example approach:
#[derive(Error, Debug)] pub enum ModelError { #[error("model not found in indexed namespaces")] NotInIndexedNamespace(String), #[error("database error: {0}")] DatabaseError(#[from] sqlx::Error), }crates/torii/core/src/processors/register_model.rs (1)
61-65: Namespace filtering implementation looks solid, sensei!The logic effectively implements selective namespace indexing while maintaining good defaults (empty list = index all). Consider these enhancements:
- Add debug logging when skipping namespaces for better observability
- Consider adding metrics/counters for skipped events
// If the namespace is not in the list of namespaces to index, silently ignore it. // If our config is empty, we index all namespaces. if !config.namespaces.is_empty() && !config.namespaces.contains(&namespace) { + debug!( + target: LOG_TARGET, + %namespace, + "Skipping model registration due to namespace filter" + ); return Ok(()); }crates/torii/core/src/processors/register_event.rs (1)
61-65: Consider adding debug logging for filtered events, sensei!The namespace filtering logic is well-implemented with clear comments and correct handling of empty config case. However, adding debug logging when events are filtered out would help with observability.
if !config.namespaces.is_empty() && !config.namespaces.contains(&namespace) { + debug!( + target: LOG_TARGET, + %namespace, + "Skipping event from non-indexed namespace" + ); return Ok(()); }crates/torii/core/src/processors/store_update_member.rs (1)
59-69: Consider documenting the error handling pattern, sensei!Since this error handling approach is specific to namespace-aware indexing, it would be valuable to document this pattern in a central location (like README.md or CONTRIBUTING.md) to ensure consistency across all processors.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (7)
crates/torii/cli/src/options.rs(3 hunks)crates/torii/core/src/processors/register_event.rs(2 hunks)crates/torii/core/src/processors/register_model.rs(2 hunks)crates/torii/core/src/processors/store_del_record.rs(2 hunks)crates/torii/core/src/processors/store_set_record.rs(2 hunks)crates/torii/core/src/processors/store_update_member.rs(1 hunks)crates/torii/core/src/processors/store_update_record.rs(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/torii/cli/src/options.rs
🔇 Additional comments (8)
crates/torii/core/src/processors/store_del_record.rs (2)
54-64: Ohayo! The error handling looks good, sensei! 🎋
The graceful handling of missing models aligns well with the namespace-specific indexing feature. The explicit comments and structured error handling make the intention clear.
56-63: Verify error string matching reliability, sensei! 🔍
The current implementation relies on string matching to detect "no rows" errors. While functional, this approach might be fragile if the error message changes.
Let's check if this error string is consistently used across the codebase:
✅ Verification successful
Let me search for the database error handling implementation to understand where this error originates.
Let me search for the actual database error type and its implementation to understand where this error message originates.
Let me search for the SQL error handling implementation to understand where this error message comes from.
Ohayo sensei! The error string matching is actually reliable! 🎯
The string matching for "no rows" is consistently used across the codebase and originates from sqlx's RowNotFound error. This is evident from:
-
The error handling pattern is consistently used in multiple processors:
- store_del_record.rs
- store_update_record.rs
- store_set_record.rs
- store_update_member.rs
-
The error comes from sqlx (SQL toolkit for Rust) as seen in the server implementation:
Error::Sql(sqlx::Error::RowNotFound)This is a standard SQL error pattern and the string matching is reliable since it's tied to sqlx's core error type.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar error string matching patterns
rg -A 2 'contains.*no rows'
# Search for the actual error string definition
rg '"no rows"'
Length of output: 1579
Script:
#!/bin/bash
# Search for database error type definitions and implementations
rg -A 5 'impl.*Error'
# Search for database-related error handling
rg -A 5 'type.*Error'
# Search for error conversion implementations
rg -A 5 'impl.*From.*Error'
Length of output: 105433
Script:
#!/bin/bash
# Search for database error type definitions and implementations
rg -A 5 'pub.*struct.*Error'
rg -A 5 'pub.*enum.*Error'
# Search for database-related modules and implementations
rg -A 5 'mod.*db'
Length of output: 47216
Script:
#!/bin/bash
# Search for SQL-related error handling and implementations
rg -A 5 'sqlx::Error'
rg -A 5 'impl.*From.*sqlx::Error'
rg -A 5 'no rows'
Length of output: 3321
crates/torii/core/src/processors/store_set_record.rs (1)
55-65: Ohayo! The error handling improvement looks good, sensei! 🎋
The new error handling gracefully handles the case where a model doesn't exist, which is expected behavior when indexing specific namespaces. The comments clearly explain the rationale.
Let's verify this pattern is consistent across other processors:
✅ Verification successful
The previous search might have been too specific. Let's try a broader pattern to catch similar error handling approaches and also identify which processor files interact with models that might need consistent error handling.
Let's examine how each of these files handles model-related errors to ensure consistency in error handling across processors.
Let's try a more specific pattern to catch the model-related error handling, focusing on the actual database calls and their surrounding context.
Ohayo! The error handling pattern is well-aligned across processors, sensei! 🎋
The verification shows consistent error handling for missing models across the processors:
store_update_member.rsstore_del_record.rsstore_update_record.rsevent_message.rs
All processors that need to handle missing models implement the same pattern of silently ignoring "no rows" errors, with appropriate comments explaining the rationale. The remaining processors (register_event.rs and register_model.rs) don't need this handling as they don't query existing models.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if similar error handling exists in other processor files
# Expected: Similar error handling in other processor files
# Search for similar error handling patterns in other processor files
rg -U "match.*model.*await.*\{.*contains.*no rows.*Ok\(\(\)\).*\}" crates/torii/core/src/processors/
Length of output: 102
Script:
#!/bin/bash
# Let's try a more flexible search pattern to find similar error handling in processor files
rg -U "match\s+.*model.*\{.*no rows.*\}" crates/torii/core/src/processors/ -A 5
# Also search for files that might need similar error handling
fd ".*\.rs$" crates/torii/core/src/processors/ --exec grep -l "model(" {} \;
Length of output: 533
Script:
#!/bin/bash
# Let's check the error handling in each file that uses model()
for file in store_update_member.rs store_del_record.rs store_update_record.rs register_event.rs register_model.rs event_message.rs; do
echo "=== $file ==="
rg -U "let\s+model\s*=.*?\{.*?\}" "crates/torii/core/src/processors/$file" -A 5
done
Length of output: 1748
Script:
#!/bin/bash
# Let's try a different approach to find model error handling
for file in store_update_member.rs store_del_record.rs store_update_record.rs register_event.rs register_model.rs event_message.rs; do
echo "=== $file ==="
rg "db\.model.*await" "crates/torii/core/src/processors/$file" -B 2 -A 10
done
Length of output: 3395
crates/torii/core/src/processors/store_update_record.rs (1)
58-68: Ohayo! Verify error handling for namespace-specific indexing
The new error handling gracefully handles non-existent models, which aligns with the namespace-specific indexing feature. However, we might want to add debug-level logging here to maintain observability.
let model = match db.model(event.selector).await {
Ok(m) => m,
Err(e) => {
if e.to_string().contains("no rows") {
+ tracing::debug!(
+ target: LOG_TARGET,
+ selector = %event.selector,
+ "Ignoring model update for non-indexed namespace"
+ );
return Ok(());
}
return Err(e);
}
};Let's verify the behavior across other processors:
✅ Verification successful
Let me check if there's any logging in these files to ensure consistency.
Ohayo! The error handling pattern is consistent across processors, sensei!
The verification shows that:
- All processor files consistently handle the "no rows" case in the same way
- Each processor has its own
LOG_TARGETconstant and proper tracing setup - Other processors already use logging for important events
Since this is a consistent pattern across the codebase and the error handling aligns with the namespace-specific indexing feature, the suggestion for adding debug logging is good but not critical. The current implementation maintains consistency with other processors.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if similar error handling exists in other processors
# Expected: Find similar patterns in other processor files
rg -A 5 "contains.*no rows" crates/torii/core/src/processors/
Length of output: 2036
Script:
#!/bin/bash
# Check for logging patterns in processor files
rg -B 2 -A 2 "tracing::(debug|info|warn|error)" crates/torii/core/src/processors/
Length of output: 3428
Script:
#!/bin/bash
# Check for LOG_TARGET constant
rg "LOG_TARGET" crates/torii/core/src/processors/
Length of output: 3572
Script:
#!/bin/bash
# Check the module structure to see if logging is defined at a higher level
ast-grep --pattern 'const LOG_TARGET: &str = $_'
Length of output: 299
crates/torii/core/src/processors/register_model.rs (1)
41-41: Ohayo! Parameter rename looks good, sensei!
The removal of the underscore prefix from _config is appropriate since the configuration is now actively used for namespace filtering.
crates/torii/core/src/processors/register_event.rs (2)
41-41: Ohayo! Parameter usage change looks good, sensei!
The removal of the underscore prefix from _config indicates this parameter is now actively used, which aligns perfectly with the new namespace filtering feature.
61-61: 🛠️ Refactor suggestion
Consider safer error handling for namespace conversion, sensei!
The namespace string conversion uses unwrap() which could panic. Consider using map_err() to provide a more graceful error handling approach.
-let namespace = event.namespace.to_string().unwrap();
+let namespace = event.namespace.to_string().map_err(|e| {
+ anyhow::anyhow!("Failed to convert namespace to string: {}", e)
+})?;Likely invalid or redundant comment.
crates/torii/core/src/processors/store_update_member.rs (1)
59-69: Ohayo! The error handling looks good, sensei! Let's verify consistency.
The new error handling pattern that silently ignores missing models aligns well with the namespace-specific indexing feature. The implementation is clean and well-documented.
Let's check if this error handling pattern is consistent across other processors:
✅ Verification successful
Ohayo! The error handling is perfectly consistent across all processors, sensei!
The verification shows that all store-related processors (store_update_record.rs, store_set_record.rs, store_del_record.rs) follow the exact same error handling pattern for missing models, silently returning Ok(()) when encountering "no rows" errors. Even event_message.rs follows a similar pattern with a simplified implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check error handling patterns in other processors
# Expected: Similar error handling for "no rows" in other processor implementations
# Search for similar error handling patterns in other processors
ast-grep --pattern 'if $_.contains("no rows") {
return Ok(());
}'
# Also check for any direct error propagation that might need similar handling
rg -A 2 'db\.model\(' crates/torii/core/src/processors/
Length of output: 2615
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
bin/torii/src/main.rs(2 hunks)crates/torii/cli/src/args.rs(2 hunks)crates/torii/cli/src/options.rs(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- crates/torii/cli/src/args.rs
- crates/torii/cli/src/options.rs
🔇 Additional comments (2)
bin/torii/src/main.rs (2)
126-126: Ohayo! Clean naming update looks good, sensei!
The simplified flag naming from index_transactions to transactions maintains functionality while improving readability.
143-143: Verify historical events handling, sensei!
The removal of unwrap_or_default() suggests that args.events.historical is now guaranteed to be initialized. Let's verify this assumption:
Also applies to: 147-147
✅ Verification successful
Ohayo! The historical events handling is safe, sensei!
The removal of unwrap_or_default() is perfectly fine because:
historicalis aVec<String>with a default implementation (vec![])- It's properly configured with clap's
argattribute for CLI parsing - The struct implements
Defaulttrait returning an empty vector
The direct into_iter() usage is safe since we'll always have at least an empty vector to iterate over.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for EventsOptions struct definition and usage
rg -A 5 "struct EventsOptions"
# Search for historical field initialization
rg "historical.*Vec<String>"
Length of output: 603
Script:
#!/bin/bash
# Let's check the field type and initialization in the CLI args
ast-grep --pattern 'historical: Vec<String>'
# Check if there's a default value or builder pattern
rg -B 3 'historical.*=.*Vec'
# Look for any clap/arg attributes related to historical
rg -B 2 '#\[arg.*historical\]'
Length of output: 110
Script:
#!/bin/bash
# Let's check how historical is used in the codebase
rg -A 2 "historical" crates/torii/cli/src/options.rs
# Check for any clap/arg attributes with a more flexible pattern
rg "#\[arg.*historical.*\]" crates/torii/cli/src/options.rs
# Look for the struct field and its attributes
rg -B 3 "pub historical:" crates/torii/cli/src/options.rs
Length of output: 724
| polling_interval: Duration::from_millis(args.indexing.polling_interval), | ||
| flags, | ||
| event_processor_config: EventProcessorConfig { | ||
| historical_events: args.events.historical.unwrap_or_default().into_iter().collect(), | ||
| historical_events: args.events.historical.into_iter().collect(), | ||
| namespaces: args.indexing.namespaces.into_iter().collect(), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Ohayo! Documentation needed for the new namespaces feature, sensei!
The addition of namespace filtering is a significant feature that deserves proper documentation. Please consider:
- Adding documentation comments explaining the purpose and usage of namespaces
- Including example configurations in the README
- Adding tests to verify namespace filtering behavior
Would you like me to help draft the documentation and test cases for this new feature?
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
crates/torii/cli/src/args.rs (1)
286-292: LGTM! Consider adding edge case testsOhayo sensei! The test assertions have been properly updated to reflect the new structure. However, consider adding test cases for:
- Non-empty namespaces configuration
- Invalid namespace formats (if any restrictions exist)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
crates/torii/cli/src/args.rs(3 hunks)
🔇 Additional comments (2)
crates/torii/cli/src/args.rs (2)
239-239: LGTM! Test assertion correctly updated
Ohayo! The test assertion has been properly updated to reflect the removal of the Option wrapper for historical events.
264-271: Verify the empty namespaces default value
Ohayo sensei! While the configuration changes look good, we should verify if an empty array is the intended default for the new namespaces field. This could affect the indexing behavior if no namespaces are specified.
Let's check if there's any documentation or related code that specifies the expected behavior:
✅ Verification successful
Empty namespaces array is the correct default
Ohayo sensei! After checking the codebase, I can confirm that an empty namespaces array is indeed the correct default. The NamespaceConfig implementation shows that when no explicit namespaces are provided, the system falls back to using a default namespace ("dojo"), as evidenced by the test_get_namespaces_default test. This means the empty array in the configuration is valid and won't affect indexing behavior negatively.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for documentation or usage of the namespaces field
rg -g '!target' -g '*.{rs,md,toml}' -B 2 -A 2 'namespaces.*=.*\[\]'
# Search for any comments or documentation about namespaces behavior
rg -g '!target' -g '*.{rs,md}' -B 3 -A 3 'namespaces.*field'
Length of output: 1112
Script:
#!/bin/bash
# Let's search for the struct definition and documentation of the namespaces field
ast-grep --pattern 'struct $_ {
$$$
namespaces: $_,
$$$
}'
# Search for any code that processes or validates the namespaces field
rg -g '!target' 'fn.*namespaces' -B 2 -A 5
# Search for any tests related to namespaces configuration
rg -g '!target' -g '*.rs' 'test.*namespaces' -B 2 -A 5
Length of output: 10253
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2687 +/- ##
==========================================
- Coverage 57.41% 57.25% -0.16%
==========================================
Files 406 408 +2
Lines 51330 51754 +424
==========================================
+ Hits 29470 29631 +161
- Misses 21860 22123 +263 ☔ View full report in Codecov by Sentry. |
Summary by CodeRabbit
Release Notes
New Features
namespacesfield in event processing configurations for enhanced categorization and filtering.Improvements
historicalevents field by removing optionality, ensuring it always contains a vector.Documentation