MQTT messages are always acked even if handler returns an error

[CodeMonkeyLeet]

Expected Behavior

MQTT pubsub and bindings components only Ack() a message if the app's callback returns without error, as documented by the Dapr APIs.

Actual Behavior

paho.mqtt.golang lib that Dapr MQTT components depend on always Ack() the message when the handler returns, even though both the pubsub and bindings components expect to be able to explicitly Ack() only on success of the app's handler.

See eclipse/paho.mqtt.golang#459 for details.

Steps to Reproduce the Problem

1. Modify the pubsub conformance test subscription handler to always return failure.
2. Run the pubsub conformance test on any of the MQTT profiles several times.
   • Observe that the component moves on to the next message once all retries (5) are exhausted (i.e. the MQTT wrapper handler has returned to mqtt lib caller), even across subsequent runs of the test.
   • Compare with a different pubsub component (e.g. Kafka), the first message is continuously redelivered as it is not successfully acked, even across subsequent runs of the test.

Release Note

RELEASE NOTE: FIX MQTT messages are always acked even if handler returns an error

[CodeMonkeyLeet]

Note that in the (breaking) v5 version of the SDK, there is an issue tracking designs for potentially addressing this: eclipse/paho.golang#53

[shivamkm07]

/assign

[shivamkm07]

paho.mqtt.golang lib fix to support switching off auto acks: eclipse/paho.mqtt.golang#578

[shivamkm07]

@artursouza this can be closed now.

[yaron2]

@artursouza this can be closed now.

Let's keep it open to track until it's updated in Dapr and resolved.