Skip to content

Commit

Permalink
Document token.Wait behaviour during reconnect
Browse files Browse the repository at this point in the history
When a connection is lost to the broker and later resumed the token
returned to the user will be considered completed and a new token will
be created instead. The result of this is that there is no way for a
user of this library to know whether a message has been delivered in the
presence of connection issues.

Signed-off-by: Linus <linus@wallgren.eu>
  • Loading branch information
ecksun committed Dec 8, 2021
1 parent 5208ce8 commit ccf1d3d
Showing 1 changed file with 3 additions and 0 deletions.
3 changes: 3 additions & 0 deletions README.md
Expand Up @@ -119,6 +119,9 @@ configure a handler with `AddRoute` or set a `DefaultPublishHandler`.
* Reusing a `Client` is not completely safe. After calling `Disconnect` please create a new Client (`NewClient()`) rather
than attempting to reuse the existing one (note that features such as `SetAutoReconnect` mean this is rarely necessary).
* Brokers offer many configuration options; some settings may lead to unexpected results.
* Publish tokens will complete if the connection is lost and re-established using the default
options.SetAutoReconnect(true) functionality (token.Error() will return nil). Attempts will be made to re-deliver the
message but there is currently no easy way know when such messages are delivered.

If using Mosquitto then there are a range of fairly common issues:
* `listener` - By default [Mosquitto v2+](https://mosquitto.org/documentation/migrating-to-2-0/) listens on loopback
Expand Down

0 comments on commit ccf1d3d

Please sign in to comment.