QuantConnect/Lean · error · RegressionTestException
Unexpected cancel event: {orderEvent}
Error message
Unexpected cancel event: {orderEvent} What it means
When an OrderEvent with Status == Canceled arrives, the regression requires the complete prior sequence: _optionSold, _optionAssigned, _stockAssigned, _optionDelistedWarningReceived, and _optionDelisted must all be true. The delisted event must precede the final cancellation confirmation. A failure means the order was canceled before the full delisting/exercise sequence completed.
Source
Thrown at Algorithm.CSharp/DuplicateOptionAssignmentRegressionAlgorithm.cs:119
else
{
throw new RegressionTestException($"Unexpected order fill event: {orderEvent}");
}
}
else if (orderEvent.Status == OrderStatus.CancelPending)
{
// We receive the delisting warning before the order cancel is requested
if (!_optionSold || !_optionAssigned || !_stockAssigned || !_optionDelistedWarningReceived)
{
throw new RegressionTestException($"Unexpected cancel pending event: {orderEvent}");
}
}
else if (orderEvent.Status == OrderStatus.Canceled)
{
// The delisted event is received before the order is canceled
if (!_optionSold || !_optionAssigned || !_stockAssigned || !_optionDelistedWarningReceived || !_optionDelisted)
{
throw new RegressionTestException($"Unexpected cancel event: {orderEvent}");
}
_orderCanceled = true;
}
}
public override void OnDelistings(Delistings delistings)
{
if (!delistings.TryGetValue(_option, out var delisting))
{
throw new RegressionTestException($"Unexpected delisting events");
}
if (delisting.Type == DelistingType.Warning)
{
if (!_optionSold || !_optionAssigned || !_stockAssigned || _optionDelistedWarningReceived)
{
throw new RegressionTestException($"Unexpected delisting warning event: {delisting}");View on GitHub (pinned to d2c3659f87)
Solutions
- Log the timestamped sequence of all OrderEvents and OnDelistings calls to find which flag is still false at Canceled.
- Verify the DelistingType.Delisted event is processed before the Canceled confirmation.
- Check for a Lean regression in delisting-vs-cancel ordering.
- If the new ordering is correct, relax the gating to require only the flags that must precede cancellation.
Defensive patterns
Strategy: validation
Validate before calling
else if (orderEvent.Status == OrderStatus.Canceled)
{
var fullyReady = _optionSold && _optionAssigned && _stockAssigned
&& _optionDelistedWarningReceived && _optionDelisted;
if (!fullyReady)
{
Debug($"Canceled before full delisting: delisted={_optionDelisted} warn={_optionDelistedWarningReceived}");
throw new RegressionTestException($"Unexpected cancel event: {orderEvent}");
}
_orderCanceled = true;
} Prevention
- Log the full event sequence to find which flag is false at Canceled.
- Verify the DelistingType.Delisted event is processed before the Canceled confirmation.
- Relax gating only after confirming the new ordering is intentional.
When it happens
Trigger: The Canceled event arrives before the option is fully delisted (_optionDelisted false), or before assignment/delivery completed — e.g., the order was canceled by a different mechanism (timeout, margin) rather than delisting.
Common situations: A Lean change in the ordering of delisting events vs order cancellation, the cancel firing before the Delisted (as opposed to Warning) delisting type is processed, or an early cancel from another source.
Related errors
- Unexpected cancel pending event: {orderEvent}
- Unexpected delisting warning event: {delisting}
- Unexpected order fill event: {orderEvent}
- Unexpected delisting events
- Unexpected delisting event: {delisting}
AI-assisted analysis of QuantConnect/Lean@d2c3659f87 (2026-08-13).
Data as JSON: /api/errors/39ac96523503d103.
Report an issue: GitHub.