Capacity estimate calculating buying power for FOPs after underlying's cache is reset

[jhonabreul]

Expected Behavior

After FOP delisting, market capacity calculation should run smoothly, it should consider that option's underlying might be already delisted and removed before trying to calculate buying power.

Actual Behavior

After FOP desliting and Future security is removed from universes, CapacityEstimate still tries to update market capacity by selecting a FOP as the smallest asset, for which buying power is beign calculated. Given that Future cache is already reset, the underlying price is 0, which causes a division by zero here.

This is happening in the case of FOP contracts that expire on a day when the market is closed, as is the case for Class III Milk in this algorithm. The capacity is beign calculated one day after the expiration date and the next time it is tried to be calculated, the division by zero happens.

One reason why a FOP is beign selected as the smalles asset even when the underlying's cache has already been reset is because CapacityEstimate.UpdateMarketCapacity tries to update tjhe market capacity for each symbol after all FOPs and future has been delisted and securities are removed from the universes, so all of their caches are reset and no more data is feed, causing GetBar to return null here, so no calculation is performed.

Potential Solution

There might be an issue with GetBar causing it to return null when it shouldn't:

• By reproducing the issue, we can se that right after the delisting happens and the securities cache gets reset, MarketCapacityDollarVolume is reset for each symbol (this is triggered by the delisting order events).
• Then, they are tried to be calculated again, which requires GetBar() to return valid data, but it doesn't , it returns null, because the securities cache is already cleared.
• This causes MarketCapacityDollarVolume to be 0 for all securities, so the next time market capacity is calculated, the smallest asset selection is not deterministic, a FOP is selected, and since the underlying is cleared, the division by zero is attempted.

Also, why is capacity being calculated for FOPs when the underlying is already removed?

Reproducing the Problem

Revert the patch to Common/Securities/FutureOption/FuturesOptionsMarginModel.cs mentioned in this PR and run DelistingFutureOptionRegressionAlgorithm

System Information

Linux (Fedora).

Checklist

• [x] I have completely filled out this template
• [x] I have confirmed that this issue exists on the current master branch
• [x] I have confirmed that this is not a duplicate issue by searching issues

• [x] I have provided detailed steps to reproduce the issue