Bug-Free vs Bug-Proof

1. Both reducing bugs and implementing error handling, as well as robust handling of restarts, are crucial for successful live deployment. It's important to backtest your trading algorithm before deploying it live to test if it has coding errors. You can stay up to date on the Lean GitHub Issues to be aware of any potential bugs or issues. Additionally, enabling automatic restarts can help improve the algorithm's resilience to temporary outages such as a brokerage API disconnection. This feature will use best efforts to restart your algorithm if it fails due to a runtime error.

2. In addition to using the Object Store, you can also use the WarmUp and History methods to reconstruct state or indicator needs. This can be particularly useful for handling unexpected restarts during live deployment.

Here is how you can iterate through the keys and values in the Object Store in Python:

for kvp in self.ObjectStore:
 key = kvp.Key
 value = kvp.Value

And here is how you can iterate through just the keys in the Object Store:

for key in self.ObjectStore.Keys:
 continue

Remember, if you save content into the Object Store from the Research Environment or a backtest after you deploy a live algorithm, you can't access the new content from the live algorithm.

Mia, I agree. API disconnects did cause me issues early on. I'm glad to hear that my use of the Object Store is a suitable solution to the restart issue.

With regard to your last statement, your live algorithms can access updated values after initial deployment. The line below (1) clears the live algorithms cache, requiring it to pull the most current values from the Object Store. I use this tactic to expedite testing by triggering trade events more frequently. Without this option, I would have to wait until the first of each month to watch the algorithm execute its trades.

As shown below (2) I also include the project ID and LiveMode in all of the Object Store keys. This helps with the separation between backtesting, live algorithms, and separate projects.

self.ObjectStore.Clear()
self.ObjectStore.Save(str(self.ProjectId)+"_"+str(self.LiveMode)+"Key")

Ethan, it seems like you've found a good solution to handle unexpected restarts during live deployment by using the Object Store. Your approach to clear the Object Store and save the project ID and LiveMode in all of the Object Store keys is a good practice for separating between backtesting, live algorithms, and separate projects.

As Mia mentioned, in addition to using the Object Store, you can also use the WarmUp and History methods to reconstruct state or indicator needs. This can be particularly useful for handling unexpected restarts during live deployment.

Here is how you can iterate through the keys and values in the Object Store in Python:

for kvp in self.ObjectStore:
 key = kvp.Key
 value = kvp.Value

And here is how you can iterate through just the keys in the Object Store:

for key in self.ObjectStore.Keys:
 continue

Remember, if you save content into the Object Store from the Research Environment or a backtest after you deploy a live algorithm, you can't access the new content from the live algorithm.

Also, keep in mind that the live environment's access to the ObjectStore is much slower than in research and backtesting. Limit the individual objects to less than 50 MB to prevent live trading access issues.

Lastly, all organizations get 50 MB of free storage in the ObjectStore. Paid organizations can subscribe to more storage space. The Resources page shows the total storage used in your organization and the storage used by individual projects so that you can easily manage your storage space.

I have been playing with object store a lot in the last 48 hours, I was having trouble generating large data sets for an ML model due to being timed out, my solution was to create an autosave method including a dictionary<string(symbol), bool (isProcessed)> the autosave will automatically output a list of unprocessed symbols to pick up from in my analysis method. it sounds like the next problem I will have is that my model won't actually be usable in the backtest or live trading stage? if that is true it really needs to be changed, what is the point of doing all that research and building models etc only to not be able to use it later, or even not being able to carry data and models between research projects and strategies? I think it's hard enough to do things in a cloud without having to start from scratch every time you progress to the next development step, it doesn't really incentivise people to use the paid service and really incentivises getting local data and using the open source engine, hopefully I am misunderstanding. the big limitation of doing things on the cloud is having to try and store everything and also the lower raw processing power, my data to train my model takes 16 hours to produce. is it possible to use the same model generated in research for testing and live trading? I feel like the platform would just be nerfed by only being able to use a model or research generated dataset once and I honestly cant fathom why that would even be the case.

Hi AgedVagabond, stored models can be used in live trading. The object store is accessible in research, backtesting, and live trading.

Ethan Hammond You're doing everything right. It is just that restoring the state is difficult and a part of algo trading. A little later this year, I'm hoping we can automatically serialize the algorithm object every so often to restore the state when it is a brokerage error. You wouldn't want to restore state of a runtime error =)

QuantConnect Team I'm glad to hear I am on the right track. I am interested in following the work on restoring an algorithm's state after brokerage errors. Additionally, I agree that runtime errors would likely persist through any restoration of an algorithm's previous state.

Nearly all of my runtime errors are a result of memory issues. The current strategy is running the fundamental universe selection on hourly data. I have refined that dataset to less than 50 assets, so this should keep me well below the 500 MB limit. I have not yet determined the cause of my ongoing memory issues. However, I am glad to hear that other efforts (error handling) are on track.