How to Recover Real-Time Stock Snapshots After a Trading Halt

When you’re building a trading bot, it’s easy to focus on signal logic and forget that market data has state. Stocks get suspended, go into auctions, or resume trading after days of silence. If your system doesn’t explicitly handle these transitions, you’ll end up with corrupted snapshots and phantom signals. Today, I’ll walk through how our team solved this at a high-frequency prop shop, and give you a reusable pattern you can drop into your own pipeline.

Scenario: The resumption that wasn’t
Imagine your strategy holds a stock that’s halted for an acquisition announcement. During the halt, your local cache shows the last trade at $50. Two weeks later, the stock reopens at $62. If your code simply updates the cache with the first new tick it receives, it may average these values, generate a false breakout, or trip a circuit breaker. We learned this the hard way when a misprocessed resumption triggered a $200k accidental unwind.

Why naive approaches fail
A quick comparison of common data access methods:

• HTTP polling – You get the latest price every few seconds, but you don’t know if the stock is halted or if the API is returning a cached response. Timestamp often remains unchanged during a halt, so you can’t detect the resume event quickly.
• Web scraping – Unreliable for state; you’ll be guessing based on screen text.
• Broker SDKs – Sometimes include status, but it may be on a different stream or require additional parsing, adding latency and complexity.

We needed an event-driven solution that delivers the trading status with the tick.

Enter tick-level state fields
This is where a professional real-time WebSocket API shines. With AllTick’s tick stream, every message includes a status indicator (e.g., “TRADING”, “HALTED”). That means you can build a state machine entirely within your message handler, no external calls necessary.

Validation fields you must check
When a halt ends, don’t trust the first tick blindly. Verify these fields:

Data Field	What It Tells You
Instrument status	Must equal “TRADING”
Timestamp	Must be newer than the halt start time
Last price	The actual post-resumption transaction price
Volume	Should be > 0 to confirm real trade
Bid/ask depths	Must be present and non-stale

We use a simple last_valid_ts variable per symbol. Every incoming tick must have timestamp > last_valid_ts to be accepted. This prevents old ticks from reordering and overriding fresh data.

The recovery flow
Here’s the step-by-step state machine we implemented:

1. Normal trading: Continuously update snapshot cache.
2. Halt detected: Freeze cache, save pre-halt snapshot as a separate object.
3. Resumption signal received: Set state to WAITING_FIRST_TICK.
4. First tick validation: Check timestamp > halt_ts, volume > 0, price ≠ null.
5. Cache unfreeze: Overwrite snapshot with validated tick and notify downstream modules (K-lines, risk, etc.).

This separation between cache and state keeps your data lineage clean and lets you replay events for debugging.

Code example
Here’s a minimal WebSocket subscriber. In real use, you’d expand the on_message function with the state checks discussed above.

import websocket
import json

# Real-time tick subscription endpoint
api_doc = "https://apis.alltick.co/websocket-api/stock-websocket-interface-api/transaction-quote-subscription"

def on_message(ws, message):
    data = json.loads(message)
    timestamp = data.get("timestamp")
    if timestamp:
        # Placeholder for state validation and snapshot update
        print("update market snapshot:", data)

ws = websocket.WebSocketApp(
    api_doc,
    on_message=on_message
)
ws.run_forever()

To productionize this, wrap the logic in a class that manages per-symbol state and timestamps, perhaps backed by Redis for persistence across restarts.

Practical recommendations

• Always run a pre-validation step before sending data to your strategy. If the status isn’t “TRADING,” skip the tick or route it to a monitoring queue.
• Keep the pre-halt snapshot for audit; it’s invaluable for post-trade analysis.
• Test your recovery with historical halt/resumption events. Replay them against your handler to catch edge cases early.

Remember: tick data is not a continuous film; it’s a series of snapshots with occasional intermissions. Respect those breaks, and your algorithms will thank you.