Executions

TradingExecution is one broker-reported fill. It has no lifecycle status. Partial or complete fill state belongs to the linked order.

Minimal execution

execution.ts

import type {
  SdkSymbolInfo,
  TradingEvent,
  TradingExecution,
} from '@tradescript/pro/sdk';

declare const symbol: SdkSymbolInfo;

export const execution: TradingExecution = {
  id: 'exec-1',
  accountId: 'acct-1',
  orderId: 'ord-9',
  positionId: 'pos-3',
  symbol,
  side: 'buy',
  quantity: 200,
  price: 184.98,
  time: 1_754_000_000_000,
  commission: 1,
  currency: 'USD',
};

export const update = {
  type: 'executions',
  executions: [execution],
} satisfies TradingEvent;

Include orderId and positionId whenever the backend supplies them. Option fills also carry the exact optionContract; the underlying ticker is not an option-position identity.

Snapshot semantics

An executions event replaces the complete execution collection. Use one stable id for one logical print, globally unique across every account in the controller.

Broker fact	Next complete execution list
First partial fill	Add one execution id.
Additional fill	Retain prior prints and add a new id.
Correction	Replace fields under the same id.
Bust	Remove the busted id.

Publishing one fill again under a new id creates a second logical execution and a second row or marker.

Retention window

TradingState.executions and every executions event are complete replacements for the adapter's current execution window. Choose and document a deterministic window, such as the current session, a rolling time range, or the last N fills. Apply the same rule in getState() and every execution event, and retain enough rows to publish corrections or busts within that window.

The trading controller has no paged execution-history API. For long-term or paged fill history, expose a backend-owned paginated Account Manager table with getAccountManagerTablePage instead of treating executions as unbounded history.

Coordinate a fill

A 300-unit order filled as 200 plus 100 produces two execution ids linked to the same order. Publish the matching order progress and resulting position. Use one state event when subscribers must observe all collections together.

Cancellation before any fill produces no execution. Never publish a synthetic zero-quantity fill for an order-state change.

Where fills appear

• Account Manager renders one row per published execution.
• Chart markers require matching exact symbol identity and a time associated with the loaded bar range.
• Positions remain broker-owned; the SDK does not net this list into exposure.

Marker placement uses execution time. Account Manager preserves the input array order by default and sorts only when its table metadata declares initialSorting or the user selects a sort. Sort each replacement snapshot in the adapter or configure initial sorting when the default order must be deterministic.

Verify the contract

• Replaying the same snapshot creates no duplicate marker.
• Two partial fills retain two stable ids and one order id.
• A correction updates the existing row instead of adding another.
• A bust removes the row and publishes any related order or position correction.
• Reconnect cannot overwrite a newer fill list with an older snapshot.

Next steps

• Positions — publish the exposure affected by the fill.
• Orders — update filled and remaining quantities.
• Account Manager — configure execution columns and focus actions.