-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Open
Description
Problem
IDataQueueHandler is currently too rigid for long-running DataSource consumers. When a breaking change is needed, we risk interface churn and downstream breakage.
Additionally, unhandled exceptions inside LongRunning tasks are swallowed by the task infrastructure and do not propagate to the main thread, which leaves the DataSource running in an undefined or stalled state.
At the moment, there is no reliable mechanism for a DataSource to notify Lean that a fatal error has occurred and that it should be terminated.
Expected Behavior
- A
DataSourceshould be able to:- Surface fatal exceptions to Lean
- Terminate cleanly when an unrecoverable error occurs
- Lean should receive a clear error signal (e.g. via
BrokerageMessageEvent) when aDataSourcefails - Future extensions to IDataQueueHandler should not require breaking interface changes
Actual Behavior
- Exceptions thrown inside
LongRunningtasks are swallowed - The
DataSourcecontinues running (or appears to) without notifying Lean - No
XXXMessageEventis emitted to indicate failure - Consumers cannot safely extend behavior without modifying the core interface
// Exception thrown here is swallowed
_dataReceiverTask = new Task(
() => MonitorDataReceiverConnection(token),
token,
TaskCreationOptions.LongRunning);
_dataReceiverTask.Start();
Potential Solution
- Introduce an extensible abstraction
- Add a base class (e.g.
DataQueueHandlerBase) that implementsIDataQueueHandler - Allow new virtual hooks without breaking consumers
- Add a base class (e.g.
- Create an extended interface
- e.g.
IExtendedDataQueueHandler:IDataQueueHandler - Optional adoption by advanced
DataSourceimplementations
- e.g.
- Add a fatal error signaling mechanism
- Allow
IDataQueueHandler/ base class to raise a Lean event on failure:
- Allow
OnMessage(new BrokerageMessageEvent(
BrokerageMessageType.Error,
"DataSource",
"Fatal error occurred. DataSource is terminating."));
- Lean should react by stopping the
DataSourcedeterministically - Centralize exception handling
- Catch exceptions inside
LongRunningtasks - Route them through the error event instead of letting them disappear
- Catch exceptions inside
Benefits
- Prevents silent failures in live data sources
- Improves observability and debuggability
- Enables safer evolution of
IDataQueueHandler - Reduces breaking changes for downstream consumers
Checklist
- I have completely filled out this template
- I have confirmed that this issue exists on the current
masterbranch - I have confirmed that this is not a duplicate issue by searching issues
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels