Skip to content

Order Flow

This page explains how orders move through the system and why retries are handled conservatively.

What It Does

  • Builds order intents in the Broker.
  • Sends orders via the REST adapter.
  • Consumes order and trade updates from the Order WS.
  • Translates FYERS updates into Backtrader order events.

Why It Exists

FYERS does not support client-provided idempotency keys. A retry after a timeout can create a duplicate live order. The order flow therefore uses a single-shot place_order and requires reconciliation on unknown states.

Order Lifecycle

  1. Strategy calls broker.buy/sell (or submit_order_intent).
  2. Broker constructs a FYERS payload and submits via Store.place_order().
  3. REST adapter sends the order once. On failure, it raises OrderUnknownStateError.
  4. Order WS messages arrive and are normalized into order updates and trades.
  5. Broker deduplicates fills and updates Backtrader order status.

Failure Handling

  • Unknown state: no retry; operator must reconcile via Order WS + orderbook().
  • Auth failure: immediate AuthError and stop.
  • Missing WS updates: broker reconciles with REST snapshots at reconnect.

Safety Implications

  • Safe behavior is to stop and reconcile rather than retry blindly.
  • Reconciliation is fail-fast by default to prevent stale trading.
  • Product types are allow-listed to prevent unsupported order types.

Scenario Example

Scenario: place_order times out. - The adapter raises OrderUnknownStateError. - The operator checks orderbook() and Order WS updates to determine if the order was accepted. - Only then should a manual retry be attempted.