Minute price data always stale when trading Moonshot strategy every minute

Technical Help
#1

I'm trying to figure out if I'm using QuantRocket incorrectly.

I'm currently trading a Moonshot strategy on intraday minute prices, and I've schedule the strategy to trade every minute via cron. Realtime prices are provided via Alpaca minute bars stream.

The problem is that every time the strategy trade command is run, Moonshot complains about stale data. i.e. When attempting to trade the strategy at 06:49:30, with latest available minute price at 06:48:00, I get the following error:

MoonshotError: no 06:49:00 data found in prices DataFrame for signal date 2022-05-02, is the underlying data up-to-date? (max time for 2022-05-02 is 06:48:00)

The solution I've come up with thus far is always passing in a review_date with a 30 second delay so that Moonshot is always looking at the latest completed minute bar. Additionally, I sleep 5 seconds before running the trade command to ensure realtime collection is complete as follows:

sleep 5 && quantrocket moonshot trade 'test-strategy' --review-date $(TZ=America/New_York date --date='now -30 seconds' +\%Y-\%m-\%d\ \%H:\%M:\%S)

Am I doing something wrong, or is this how Moonshot should be used? It just seems odd that the default would require such workaround; makes me feel like I'm doing something wrong. The issue may be that Moonshot is timeframe agnostic so can't really bake in any assumptions. If that's the case, I'm just looking for some confirmation that my approach follows best practices.

#2

The original use case was aggregating tick data into minute bars using the realtime service, which results in partial bars for the current minute, meaning Moonshot does not complain in that case. Using native minute aggregates from Alpaca or Polygon doesn’t give you partial minute bars, so Moonshot’s expectation is overly strict in that scenario. The challenge is that Moonshot doesn’t really have an easy way to know what scenario it’s in. It’s better for Moonshot to be a little too strict than too lax, so your workaround is probably the best solution for now.

1 Like
#3

That makes perfect sense. In fact, I really appreciate that the system is setup so well to handle tick data as I def have a number of strategies I'm working on that will require closer to realtime data. Thanks Brian!