Alpaca Signal/Margin/Moonshot Bug

[kevinkurek]

We noted in this ticket and this ticket that Alpaca's change of AccountID to purely numeric is causing issues, but this feels like a Moonshot talking to Alpaca issue.

I have 2 algos, 1 at IB and 1 at Alpaca. If the IB algo gets a "1" for a signal, but the account already has full positions, target_weights_to_positions() and order_stubs_to_orders() take care of not allowing another trade; which is expected.
But as you can see in Alpaca, it's still sending a 1 signal to buy more even though the account is full.

I have cleared this particular Alpaca account twice. If it receives 1's multiple days it will try to buy even beyond the ~2X margin at Alpaca.
If the summary is, this will be fixed in the 2.5 release, that's fine, but wanted to note this just in case it was a bug in Moonshot talking to Alpaca independent of the AccountID.

[Brian]

If you are getting an unexpected order quantity, my advice would be to step through the docs on how Moonshot calculates order quantities combined with manually querying the relevant blotter APIs in order to try to pinpoint where the unexpected thing is happening. From the information provided I can't say.

[kevinkurek]

Alpaca Actual: 117
from quantrocket.blotter import download_positions

I did the Moonshot calculates order quantities by hand.

Target_Weight = 1
Acct Allocation = 1
Target Weight Acct = 1 * 1 = 1
NLV = 22,731
Trade Value = 22,731 * 1
Mkt Price (on 3/5) = 383.63
Contract Val = 383.63
Target Quantity = 22731/383.63 = 59.252
Positions Blotter = 466
Current Open = 0
Required = 59 - 466 - 0 = -407

Clearly the blotter thinks it has way more positions than it really should, but even if that was the case I'd expect a sell order for the -407 required order quantity.
I can't see if there are any dangling positions by checking download_executions due to the error below.

download_executions error.

Here's a piece of the detailed log: