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

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' and will fail on messages which don't specify a Quality of Service.

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' and will apply the 'defaultQoS' to messages which don't specify a Quality of Service.

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 the emitted pass-through value signals that all messages to publish which came before the message were published, but conversely means potentially longer delays between successful publication and emission.

All incoming messages must specify a QoS; the stream will fail when encountering a message which doesn't specify a QoS.

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 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 (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 the emitted pass-through value signals that all messages to publish which came before the message were published, but conversely means potentially longer delays between successful publication and emission.

Message-specific QoS values take precedence over the 'defaultQoS'.

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 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 (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 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.

All incoming messages must specify a QoS; the stream will fail when encountering a message which doesn't specify a QoS.

This 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 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 (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 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.

Message-specific QoS values take precedence over the 'defaultQoS'.

This 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 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.