Skip to content

Run past consolidators before scheduled events#9542

Open
yinli-systems wants to merge 2 commits into
QuantConnect:masterfrom
yinli-systems:kevin/fix-scheduled-events-after-consolidators
Open

Run past consolidators before scheduled events#9542
yinli-systems wants to merge 2 commits into
QuantConnect:masterfrom
yinli-systems:kevin/fix-scheduled-events-after-consolidators

Conversation

@yinli-systems

@yinli-systems yinli-systems commented Jun 17, 2026

Copy link
Copy Markdown

Description

Fixes #8649.

AlgorithmManager.Run currently scans past scheduled events before scanning past consolidators. When the engine catches up over a period with no data, a scheduled event can run before a due consolidator scan updates registered indicators, so the scheduled callback observes stale indicator state.

This moves the past consolidator scan ahead of ScanPastEvents while preserving the same performance tracking blocks. The added regression test runs AlgorithmManager with a single time-pulse slice and asserts that the realtime handler only scans past scheduled events after a due consolidator scan has run.

Related

Related to #5595.

Testing

Validated after merging the current upstream master (through 0136529cd), using .NET SDK 10.0.302 on macOS Arm64:

dotnet test Tests/QuantConnect.Tests.csproj \
  --filter "FullyQualifiedName~ScheduledEventsRunAfterPastConsolidators" \
  --logger "console;verbosity=minimal"

Result: passed, 1 test.

The regression test was also fault-injected by temporarily restoring the old ordering. It failed at AssertConsolidatorScannedBeforeScheduleHandler.ScanPastEvents, confirming that the test detects the stale-indicator ordering bug. After restoring the fix, the same test passed again.

AI assistance

AI assistance was used to revalidate the implementation, run the fault-injection check, merge current upstream changes, and refine this PR description. The resulting changes and test behavior were reviewed before submission.

@yinli-systems

Copy link
Copy Markdown
Author

Follow-up with the intended behavior this PR is trying to lock down: when a scheduled event and a consolidator are both due at the same frontier time, the consolidator should be advanced first so the scheduled event observes the latest completed bar, not stale state from the previous frontier.

The regression test covers that ordering directly. I kept the change localized to the time-slice ordering path rather than changing scheduled event semantics more broadly. Happy to adjust if there is a more appropriate Lean convention for this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The Schedule runs before the Consolidator's Callback regardless of the time

1 participant