Datasource down or faulted

Symptom

One of two things:

• Enabling the flow fails. On Task Manager, the flow’s Enabled toggle bounces back to off and a message names the problem, such as “Could not connect to the datasource”.
• A running source faults mid-stream. A previously streaming flow stops producing predictions and a red banner appears. Under the hood the runtime dropped to a faulted, then idle, state.

Note

Enabling a flow does not start streaming. It prepares the runtime (loads the model, connects the adapter). You press Start in the flow’s Inference column to begin. A flow that is enabled but not predicting is often just waiting for Start — that is by design.

Confirm

Identify which stage failed.

• Read the message. It names the failed step:

  • “Could not connect to the datasource” (adapter_connect_failed) → the protocol connection (OPC-UA handshake / MQTT broker connect) failed — almost always a network or endpoint problem.
  • exactly_N_tags_required → the input’s tag mapping is incomplete.
  • A shape mismatch → the model no longer fits the input’s window size and tag count, or an output’s tag count.

• Check the backend log for the connect attempt and fault reason. Each flow enable and disable is logged with the flow name:

  docker logs aiboard-backend-real 2>&1 | grep -iE "flow|datasource|adapter|fault"

• A mid-stream fault comes from a read error on the live source (a tag stopped responding). When that happens the runtime tears down to a clean idle state: the model is unloaded and the adapter is unbound. The flow still shows enabled. Recovery is not automatic — the flow must be re-enabled.

Fix

1. Connection failure — the runtime could not reach the source. The enable already rolled the flow back to off cleanly, so fix the connection and retry:

   • Verify the endpoint address, port, and credentials in the datasource config.
   • Confirm the box has network reachability to the OPC-UA server / MQTT broker / device.
   • For a CSV source, confirm the file path and that the file is present and readable.
   • Use the form’s Test Connection against the current values, then enable the flow again.

2. Incomplete mapping — open Mapping on the input datasource, map every channel, save, then enable the flow again.

3. A source that faulted mid-stream has been torn down to idle — the model was unloaded and the adapter unbound. Re-establish it fully:

   • Fix the underlying source problem (reconnect the sensor / restore the tag / fix the network).
   • Toggle the flow off, then on again. This reloads the model and reconnects the adapter.
   • Press Start to resume streaming.

Caution

Only one flow can be enabled at a time. Enabling flow B turns flow A off, after a confirmation that names flow A. Some datasource edits also turn a flow off: saving a changed connection, a new tag mapping, or a new tag count, window size or sampling period. If a flow you expected to be running shows disabled, check whether one of these happened.

Prevent

• Map all channels before going live. Most enable failures are pre-flight validation: an incomplete tag-to-channel mapping, or a model that no longer fits the input. Complete the mapping once and the flow enables first try.
• Stabilise the source before Start. A flaky OPC-UA endpoint or intermittent broker will fault the stream and force a full re-enable. Confirm a stable connection with Test Connection before pressing Start.
• Expect the two-step flow. Enable prepares; Start streams. Building this into the operating procedure avoids “it’s enabled but nothing’s happening” tickets.

Related

• Flows — enable, switch, and disable the pipeline.
• Connecting Datasources — adapter types, connection config, tag mapping.
• Your First Inference — model load and run flow.