I've seen something similar when I put in an order_target_percent() order while an existing order_target_percent() order is still open for that security. When I put in a check for open orders in that security before every order the problem went away, so you can use that for a quick fix.

def has_orders(context):
# Return true if there are pending orders.
has_orders = False
for sec in context.secs:
orders = get_open_orders(sec)
if orders:
for oo in orders:
message = 'Open order for {amount} shares in {stock}'
message = message.format(amount=oo.amount, stock=sec)
log.info(message)

        has_orders = True  
return has_orders  

Sometimes I decrease the initial money to, say, 10K, then problem solved. I guess it's because if it's 1M there will be no enough liquidity, and open orders get accumulated.

@Kevin Q. Added test for open orders which eliminated the short positions. Thanks.

    for stock in data:  
        if (get_open_orders(stock)):  
            continue  
        order_target_percent(stock, 1.0 / stockCount)  

Oddly there was just one short, at the end of the run...???

2014-11-21PRINT!!! Short position EWZ qty: -348

For the Quantopian folks, I haven't looked at your underlying code but I assume that the order_target_percent() function puts in new orders based on existing positions without consulting pending orders. On long closeouts this leads to unexpected short positions, on shorts it leads to runaway short positions. You may want to put a warning in the documentation to check for open orders before using this function as a short term fix, and long-term you might want to consider a more defined way for the function to handle open orders. Counting them when calculating percentages would seem to make the most sense, but there may be issues with that I haven't thought of.

Help says: "Specify long_only to prevent the algorithm from taking short positions." Above shows that is not so.
"does not apply to existing open orders or positions in your portfolio" sounds like set_long_only() means -- first transaction only per sym buy only, otherwise no shorting restrictions, because once transacted, always in portfolio.positions even if zero.
You need to write your own conditions to prohibit shorting.

@Kevin, yes the order_target functions only consider the existing positions, not the open orders, when making their target calculations. I think this behavior can be improved, and in the meantime, we can add this caveat to the help documentation.

You found the right fix - to check for open orders before making further calculations.

Handling the tedious intricacies of open orders, cancels, cancel-too-lates, late-reported-fills etc is exactly what it would be helpful if Quantopian did! If everyone's algorithm needs the same wall of boilerplate python to handle too-common corner cases, then I think the platform has fallen short...

@Simon T., Indeed! Pareto, Pareto, where for art thou Pareto!

You should see some of the order handling contingency trees we've had to build. 20% straight arrow, shoot straight through. 80% nightmare of special FIX messages (some standard -- HA!), special verbiage on broker option comments; broker A can't do size amends so must convert to cancelreplace; broker B can't handle price cancelreplace, have to submit cancel and then new limit/stop. It never ends.

Traders just want to trade; quants just want to quant. Systems are supposed to deal with the ugly underbelly of broker foibles and expectation exceptions. But, it's no easy task and assumptions must be made along the way. Herding cats down the runway, some are bound to get loose.