Initialize the Environment from command line options.

Checks that command line options match a given HeadState. This function takes Environment because it is derived from RunOptions via initEnvironment.

Throws: ParameterMismatch when state not matching the environment.

A draft version of the HydraNode that holds state, but is not yet connected (see connect). This is commonly created by the hydrate smart constructor.

Hydrate a DraftHydraNode by loading events from source, re-aggregate node state and sending events to sinks while doing so.

Create a network input with corresponding default ttl from given sender.

Connect chain, network and API to a hydrated DraftHydraNode to get a fully connected HydraNode.

Fully connected hydra node with everything wired in.

Run the network hand-off and its stall monitor concurrently with the given action, stopping when any of them does. An effect throwing therefore still takes the node down, as it did when effects ran on the main loop.

NOTE: it takes it down asynchronously, though, where running inline threw synchronously from between two effects. The main loop is now cancelled wherever it happens to be, which can be mid-processStateChanges. That is the same class of interruption the surrounding withChain/withNetwork brackets could already deliver, but this is a new source of it.

Report the network hand-off stalling and recovering as Connectivity events, which reach the event log and from there clients already listening. A client connecting mid-stall is told instead by NetworkInfo, which reads the outbox live rather than replaying these - past outputs are only replayed on request, and a replayed stall may long since have ended.

These reports travel as network inputs, so while the node is catching up updateCatchingUpHead parks them and a stalled/resumed pair only reaches clients once it is in sync, by which time the stall it describes may be over. NetworkInfo is unaffected, being read live.

Only a status seen on two consecutive polls is reported, so clients are not flooded (as with the sync status, see #2749). Without that, a network completing something every so often but less often than the stall period flaps between the two reports forever: with completions 15s apart and a 10s poll, the observed gaps cycle 9s, 4s, 14s, giving a report every ~30s indefinitely.

When the node starts refusing the client transactions that grow the outbound backlog, and when it reports the backlog to clients. Ten seconds of no progress, or of backlog at the recent drain rate, is comfortably above the etcd broadcast loop's one second retry and far below any contestation period. The cap on queued messages is the memory backstop: each holds at most a maximum size transaction, so ~160MB at the cap, and it sits well above the bursts a client can fire at a node whose network is keeping up.

Deliberately not operator-configurable: the useful range is narrow, nothing observable would tell an operator which value to pick, and the natural guess for "off" (zero) is the most aggressive setting rather than the least.

NOTE: this measures the hand-off, and the shipped $sel:broadcast:Network completes as soon as the message is in the network component's own 100-slot pending-broadcast queue. So during an outage the first ~100 messages still complete promptly and nothing is reported; the stall only becomes visible once both queues are saturated, which also puts the real in-flight bound around $sel:maxPending:StallBounds plus that queue rather than at $sel:maxPending:StallBounds.

Client inputs that turn into a broadcast directly, and so are the ones worth refusing: the protocol's own messages cannot pile up while the network is down, because $sel:broadcast:Network is self-delivering, so our own AckSn never comes back, the confirmed snapshot number freezes and snapshotInFlight caps both ReqSn and AckSn at one apiece.

NOTE: that cap is not airtight, and this is not a complete bound. onOpenChainTick emits a ReqSn on a chain tick with no network input at all, and SideLoadSnapshot - which broadcasts nothing itself, so is not listed here - clears exactly the state that cap reads. A client looping SideLoadSnapshot can therefore draw one further ReqSn per tick. Left ungated on purpose: side-loading is the documented recovery for a ReqSn or AckSn lost from the hand-off, so refusing it while stalled would block the way out. The leak is one small message per chain tick.

Whether growsBroadcastBacklog inputs would reach the code that broadcasts, rather than being answered by the sync or head-state checks.

The maximum number of times to re-enqueue a network messages upon Wait. outcome.

The maximum number of times to re-enqueue ReqTx and ReqDec network messages upon Wait.

The time to wait between re-enqueuing a Wait outcome.

Monadic interface around update.

Handle to access and modify the state in the Hydra Node.

Initialize a new NodeStateHandler.