This detailed breakdown covers the lifecycle of a trade within the application, from signal parsing through multi-order placement, dynamic TP adjustments, breakeven logic, modification handling, and final closure synchronization. The use of strategies, order groups, and scenario-based adjustments are key complexities.

I. Signal Reception and Processing

1. Source: Trading signals are received as text messages from a specific Telegram channel, identified by TELEGRAM_CHANNEL_ID in the configuration.
2. Detection: The TelegramClient monitors the designated channel for new messages (events.NewMessage).
3. Initial Storage: Upon receiving a new message:
   • The system checks if a Signal record with the same message_id already exists in the database to prevent duplicate processing.
   • If it's a new message, a Signal record is created in the database with status = SignalStatus.NEW, storing the raw message text, channel ID, message ID, and timestamp.
4. Parsing:
   • The raw message text is sent to the OpenAI API (parse_signal function) using a pre-defined prompt (likely fine-tuned, model ID: ft:gpt-4o-mini-2024-07-18:personal:ttmt-gtmo:B7lt3QCz).
   • The goal of parsing is to extract structured trading information into a ParsedSignal object. This includes:
     • action: The primary intent (e.g., new_trade, modify_trade, nothing).
     • command_type: A more specific command for modify_trade actions (e.g., set_breakeven, adjust_sl).
     • symbol: The trading instrument (defaults to config.SYMBOL if not detected).
     • direction: buy (long) or sell (short).
     • zone: An optional entry price range (e.g., "1850.5 - 1848.0").
     • zone_top, zone_bottom: Numerical values extracted from the zone.
     • stop_loss (SL): A specific price level or potentially a descriptive adjustment (like "+20 pips").
     • take_profits (TPs): A list of potential take profit price levels (e.g., [1860.0, 1875.5]).
     • tp_open: A boolean flag indicating if the final TP is open-ended (not explicitly used in placement logic shown, but parsed).
     • risk_level: 1 (normal) or 2 (high risk), affecting lot size.
5. Parsing Outcome & Status Update:
   • If parsing is successful, the extracted JSON data is stored in the parsed_data field of the Signal record, and its status is updated to SignalStatus.PARSED.
   • If parsing fails (e.g., OpenAI error, invalid JSON), the Signal status is updated to SignalStatus.FAILED, and the error message is stored in meta_data.
6. Processing Queue: A separate process (process_new_trades) periodically polls the database for signals with status = SignalStatus.PARSED.

II. New Trade Execution (action == "new_trade")

1. Trigger: A signal with status == SignalStatus.PARSED and action == "new_trade" is picked up by the trade_processor.
2. Signal Status: The signal status is immediately updated to SignalStatus.PROCESSING.
3. Strategy Selection: The application uses a trading strategy determined by the CHANNEL_STRATEGY configuration setting (e.g., DefaultStrategy, GTMOStrategy, BENStrategy, BENGabrielStrategy).
4. Trade Record Creation:
   • A unique trade_id is generated (typically trade_ + signal_id).
   • A client_id is generated using the strategy name, symbol, and signal ID for linking broker orders/positions back to the trade.
   • A new Trade record is created in the database with status = TradeStatus.OPEN, linking it to the signal_id.
5. Parameter Calculation:
   • The selected strategy's compute_trade_parameters method is called.
   • It uses the ParsedSignal data and the current market_price (fetched from MetaAPI).
   • It calculates/confirms absolute price levels for SL and TPs (TP1, TP2, TP3). If the signal provided valid levels, those are typically used; otherwise, default pip distances from config.py (e.g., TP1_DEFAULT, SL_DEFAULT) are applied relative to the market price.
   • It determines the base lot size based on the risk_level (using DEFAULT_LOT_SIZE or HIGH_RISK_LOT_SIZE from config).
   • It processes any entry zone information.
   • The calculated parameters (SL, TPs, zone details, volume) are stored in the Trade record.
6. Order Definition:
   • The strategy's compute_order_definitions method is called.
   • This method returns a list of dictionaries, each defining an order to be placed. Crucially, strategies like Default, GTMO, and BEN define multiple orders (typically 12) spread across layers/groups.
   • Order Groups: Orders are logically grouped (usually 1 to 4).
     • Group 1: Market Orders (placed immediately at the current market price).
     • Groups 2, 3, 4: Limit Orders (placed to trigger if the price moves favorably into the entry zone or towards predefined offset levels).
   • Order Structure (Typical): Each group often contains multiple orders (e.g., 3 orders: 'a', 'b', 'c') targeting different TPs.
     • Order xa: Targets TP1
     • Order xb: Targets TP2
     • Order xc: Targets TP3 (or might be TP2/Open TP depending on strategy)
   • Volume Distribution: The base lot size is distributed across all defined orders based on percentages specified within the strategy (e.g., layer_volumes).
   • Limit Prices: For limit orders (Groups 2-4), entry prices are calculated based on:
     • The provided zone (e.g., distributed between zone_top and zone_bottom).
     • Or, if no zone, based on configured pip offsets from the initial market price (e.g., ORDER_GROUP_2_DISTANCE).
   • Take Profit Assignment: Each order definition specifies its target TP price (tp_price) and the corresponding level (tp_level, e.g., "tp1").
   • Stop Loss: All orders within the same trade share the same initial SL price calculated in the parameters step.
7. Order Placement:
   • The TradeExecutor iterates through the order definitions.
   • It connects to the MetaAPI streaming connection.
   • Market Orders (Group 1): Placed immediately using create_market_buy_order or create_market_sell_order.
   • Limit Orders (Groups 2-4): Placed using create_limit_buy_order or create_limit_sell_order with their calculated limit prices.
   • Validation: Before placing limit orders, the system checks if the calculated limit price is valid relative to the current market price and broker stop levels. Prices might be adjusted slightly if too close to the market.
   • Client ID: The generated client_id is attached to each order request.
8. Database Updates (Orders & Positions):
   • For each successfully placed order via MetaAPI:
     • An Order record is created in the database, storing details like MetaAPI orderId, type, direction, volume, price, SL, TP, tp_level, name (e.g., "order1a"), and order_group. The client_id is also stored. The initial status is OrderStatus.OPEN.
   • For market orders (Group 1), which fill immediately:
     • The corresponding Order record status is updated to OrderStatus.FILLED.
     • A Position record is created in the database. It shares the same ID as the filled market order (position_id == MetaAPI orderId/positionId). It stores entry price, volume, SL, TP, tp_level, name, order_group, etc. The status is PositionStatus.OPEN.
     • The position_id is added to the positions list in the parent Trade record.
9. Final Trade Update:
   • The list of all placed MetaAPI orderIds is added to the orders list in the parent Trade record.
   • The filled_order_groups list in the Trade record is initialized (typically with [1] because market orders are filled).
   • The Trade record is updated.