Greptile Summary

This PR fixes two critical timing issues in derived stream processing when delays are configured. The first issue occurs when a derived stream has a non-zero delay - the temporal calculations can result in invalid time ranges where start_time > end_time, causing pipeline failures. The second issue involves duplicate results when updating derived stream pipelines because the system would delete and recreate scheduled jobs, resetting their timing state.

The solution involves three key changes:

1. Added helper methods to PipelineSource enum (src/config/src/meta/pipeline/components.rs): The is_scheduled() and is_realtime() methods provide clean type checking capabilities using idiomatic Rust pattern matching with the matches! macro.

2. Modified pipeline update logic (src/service/pipeline/mod.rs): The update_pipeline function now conditionally deletes derived stream triggers only when the pipeline source type changes from scheduled to realtime, rather than always deleting on any update. This preserves the scheduled job's next_run_at timing state.

3. Enhanced scheduler validation (src/service/alerts/scheduler/handlers.rs): Added comprehensive validation in handle_derived_stream_triggers to detect invalid time ranges where start > end time. When detected, the system gracefully skips to the next scheduled run with proper status reporting (TriggerDataStatus::Skipped) and improved logging.

These changes work together to maintain temporal consistency in derived stream processing while preserving scheduled job state during updates, preventing both timing failures and data duplication.

Confidence score: 4/5

• This PR addresses well-defined timing bugs with a logical approach that preserves scheduler state
• Score reflects complex scheduler logic changes that require careful testing in production scenarios
• Pay close attention to the scheduler validation logic in handlers.rs for potential edge cases

_{3 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}