Create a context-preserving flow which unconditionally publishes incoming messages to MQTT with a pass-through value of 'Done'. This stage has the same semantics as 'orderedFlow'.

Create a flow which conditionally publishes to MQTT and emits a pass-through value (e.g. a checkpoint or offset to be committed) downstream. The pass-through being emitted may be treated as proof that the message to publish (if there is one) was published with the applicable QoS (AtMostOnce will emit after the message has gone out "over the wire", AtLeastOnce and ExactlyOnce will emit after the broker has signalled acceptance of the message).

This stage will emit pass-throughs in the order received. This means that an emitted pass-through value signals that all messages to publish which came before that message were published, but conversely means potentially longer delays between successful publication and emission.

If no 'defaultQoS' is specified, all incoming messages must specify a QoS (or else the stream will fail when encountering a message which doesn't specify a QoS). Message-specific QoS values take precedence over any stage default.

The stage will backpressure if there are 'concurrency' elements in progress or waiting for emission.

Calling drain on the materialized MqttControl will cause this stage to cancel demand and wait for in-flight publish attempts to complete before stopping. The returned future is completed when the draining has started.

Calling shutdown on the materialized MqttControl will cause the stage to immediately stop. In-flight publish attempts may or may not ultimately succeed.

Create a flow which conditionally publishes to MQTT and emits a pass-through value downstream. The pass-through being emitted may be treated as proof that the message to publish (if there is one) was published with the applicable QoS (AtMostOnce will emit after the message has gone out "over the wire", AtLeastOnce and ExactlyOnce will emit after the broker has signalled acceptance of the message).

This stage might not emit pass-throughs in the order received: the emission of a particular pass-through does not suggest anything about whether any other message was published. In particular, checkpoints or offsets to be committed should not be used as pass-through values with this flow; this ability to reorder may mean less of a delay from successful publication to emission.

If no 'defaultQoS' is specified, all incoming messages must specify a QoS (or else the stream will fail when encountering a message which doesn't specify a QoS). Message-specific QoS values take precedence over any stage default.

The stage will backpressure if there are 'concurrency' elements in progress.

Calling drain on the materialized MqttControl will cause this stage to cancel demand and wait for in-flight publish attempts to complete before stopping. The returned future is completed when the draining has started.

Calling shutdown on the materialized MqttControl will cause the stage to immediately stop. In-flight publish attempts may or may not ultimately succeed.