Data Model Updates#

The Alert struct has been expanded to include several new fields and methods that improve alert tracking and processing. The struct now contains an id (UUID), severity (using the AlertSeverity enum), title, description, detection_rule_id (string), process_record, timestamp, deduplication_key, and context (an AlertContext object). The deduplication_key is formatted as <severity>:<detection_rule_id>:<title>, supporting efficient alert deduplication. The AlertSeverity enum supports four levels: Low, Medium, High, and Critical, and implements string parsing and formatting for serialization and display. The AlertContext struct holds additional metadata, including key-value data, tags, source, and an optional confidence score (float between 0.0 and 1.0) with validation logic for confidence values. Builder-style methods allow for fluent addition of context data, tags, source, and confidence to alerts. The struct also provides methods to compute alert age in seconds and to check if an alert is recent based on a configurable threshold, with a convenience method to use the configured threshold from AlertingConfig (source).

Serialization Improvements#

Serialization and deserialization for Alert and related structs are implemented using serde, ensuring compatibility with JSON and other formats. Comprehensive tests confirm that alerts can be serialized to and deserialized from JSON without data loss or corruption. The AlertSeverity enum and AlertContext struct also support serialization, and tests verify correct parsing and formatting of severity levels and context data (source).

Configuration Enhancements#

The AlertingConfig struct now includes a recent_threshold_seconds field, which defines the threshold (in seconds) for considering an alert as recent. The default value is 3600 seconds (1 hour). This value can be overridden via the environment variable {COMPONENT}_RECENT_THRESHOLD_SECONDS, allowing operators to tune alert recency without code changes. The configuration loader supports hierarchical overrides from system config, user config, environment variables, and command-line flags. The configuration module includes tests for default values, environment variable overrides, validation, and serialization of AlertingConfig, including the new recent_threshold_seconds field (source).

Detection Rule Identification#

Detection rules are now identified by a strongly-typed RuleId, which is a wrapper around a string. The DetectionRule struct includes fields for id, name, description, sql_query, severity, version, author, timestamps, an enabled flag, tags, and metadata. The detection engine manages rules keyed by their RuleId, and loading a rule with a duplicate ID will overwrite the existing rule. The DetectionRule struct provides a validate_sql method that parses and validates the SQL query, ensuring it is a single SELECT statement and does not contain banned functions or unsafe constructs. Rules can be enabled or disabled dynamically, and methods for tagging and metadata update the rule's updated_at timestamp (source).

Testing Coverage Improvements#

Testing coverage has been significantly expanded. There are comprehensive unit tests for alert creation, serialization, severity parsing and display, context handling, confidence validation, alert age and recency checks (including custom thresholds and configuration), and deduplication key logic. The configuration module is tested for default values, environment variable overrides, validation, and serialization. Detection rules are tested for creation, serialization, SQL validation (including banned functions and structural constraints), enabling/disabling, tagging, and metadata operations. The detection engine is tested for rule loading (including duplicates and invalid SQL), rule removal, enabling/disabling, and rule execution scenarios with expected alert generation (alert model and config), (detection engine), (detection rule).

Impact on Alert Processing#

These changes collectively improve alert processing by enabling more precise recency filtering (via recent_threshold_seconds), better rule identification and management, safer and more robust detection rule validation, and more reliable serialization and configuration handling. Alerts now carry richer metadata, support deduplication, and can be filtered based on recency using configurable thresholds. Detection rules are more strictly validated and managed, reducing the risk of unsafe or misconfigured rules affecting alert generation. The expanded test coverage increases reliability and confidence in the alerting and detection subsystems (source).