Module node 

Live trading node built on a single-threaded tokio event loop.

The node owns system lifecycle and the event loop. Its reconciliation module schedules checks, manages report futures and deadlines, and dispatches results. The execution manager owns reconciliation state, discrepancy decisions, and individual reconciliation operations.

LiveNode::run() drives the system through a tokio::select! loop that multiplexes data events, execution events, trading commands, timers, and periodic maintenance tasks (reconciliation, purge, prune, audit).

Threading model

The core types (ExecutionManager, ExecutionEngine, Cache) use Rc<RefCell<..>> and are !Send. All access happens on the same thread. Pending report futures can retain client borrows while other select branches run. The client facade defers instrument updates until those borrows are released; completion and cancellation paths flush the deferred updates. Single-threaded execution does not by itself prevent conflicting borrows or reentrant callbacks.

Startup sequencing

Startup connects clients in two phases so that instruments are in the cache before execution clients read them:

1. Connect data clients (instruments arrive as buffered DataEvents).
2. Flush all pending data events and commands into the cache via flush_pending_data, which loops try_recv on the channel receivers until no items remain.
3. Connect execution clients (load_instruments_from_cache now finds populated instruments).
4. Drain remaining events, then run reconciliation.

Both run() (integrated event loop) and start() (manual lifecycle) follow this sequence.

Reconciliation

Continuous inflight, open-order, and position checks run on independent intervals. The shared maintenance timer in the select loop dispatches reconciliation at the minimum enabled interval. Each dispatch the handler checks which sub-checks are due based on elapsed nanoseconds and schedules their work. Continuous checks do not await venue HTTP in the select loop: open-order and position checks poll bulk venue report futures from the loop.

Maintenance dispatcher

Six periodic tasks share a single coarse maintenance_timer:

• reconciliation (inflight, open, position sub-checks)
• purge closed orders
• purge closed positions
• purge account events
• own-books audit
• recent-fills cache prune

The runner wakes one timer per loop iteration regardless of how many maintenance tasks are configured. Each task tracks its own next_fire: Instant and the dispatcher fires the bodies whose deadline has passed, rescheduling next = now + interval (equivalent to MissedTickBehavior::Delay). Disabled tasks anchor on a far-future next that never trips.

The 100ms timer cadence is the effective floor for any maintenance interval. Configured intervals below 100ms (the config types allow inflight_check_interval_ms and own_books_audit_interval_secs smaller) become eligible on the next maintenance tick. Event processing and runtime scheduling can delay dispatch further; the timer does not guarantee a maximum delay.

Re-exports

pub use builder::LiveNodeBuilder;

Modules

builder

Builder for constructing LiveNode instances.

config

Configuration types for live Nautilus system nodes.

plugin

Live-node plug-in support.

Structs

LiveNode

High-level abstraction for a live Nautilus system node.

LiveNodeHandle

A thread-safe handle to control a LiveNode from other threads.

RunnerChannelMetricsSnapshot

Primitive metrics for one LiveNode::run dispatch channel after startup.

RunnerMetricsDelta

Derived deltas between two LiveNode::run runner metrics snapshots.

RunnerMetricsSnapshot

Primitive metrics for LiveNode::run dispatch and loop work after startup.

Enums

NodeRunMode

Determines which lifecycle responsibilities the node owns while running.

NodeState

Lifecycle state of the LiveNode runner.