[mosquitto-dev] unsubscription error

[Greg Troxel <gdt@xxxxxxxxxx>]

I have two mosquitto instances, and one bridges to the other.  I used to
bridge

  topic sensor/# both

even though some are written on each, which I know is lame, but the loop
detection worked fine.  However, the ESP8266 that writes
topic/sensor/bar/temperature is not reporting, and I found that a
disconnect/reconnect of the bridge would republish it.   So I wanted to
prune bridging to the right things in the right direction.

I wrote things like:

  topic sensor/bar/hass/# out
  topic sensor/bar/baz-ups/# out

  topic sensor/bam/hass/# in

  topic weather/bar/loop out

which should be ok, but I was getting

  May 24 11:15:23 broker2 mosquitto[11576]: New bridge connected from [ipaddress] as bridge.broker1.example.com (p2, c0, k60, u'bridge.broker1').
  May 24 11:15:23 broker2 mosquitto[11576]: Invalid unsubscription string from bridge.broker1.example.com, disconnecting.
  May 24 11:15:23 broker2 mosquitto[11576]: Socket error on client bridge.broker1.example.com, disconnecting.

and none of my "out" topics from broker1 where arriving at broker2.  I
then added:

  bridge_attempt_unsubscribe false

and then basically everything worked ok (modulo me getting the topics
right, but that was not mysterious).

Later I added:

  cleansession true

to clear out things, and I also took both brokers down at the same time,
with neither persisting, to ensure old stuff was gone.  Since the
connection rarely breaks, I figure that cleansession doesn't hurt much
in load, and it helps in avoiding potential confusion.


So:

  When the unsubscription happens, it seems entirely possible that it is
  because a "topic foo out" line was added, and therefore that it is
  reasonably likely that there will not be a matching subscription.  I
  am unclear on what provoked the "invalid", but it seems obvious that a
  client attempting an unsubscribe on something it is not subscribed to
  should not be an error.

  It would be nice to log the invalid string and why, so that the admin
  can diagnose more easily.

  With cleansession, it seems there should be three options:
    never
    on first connect of this broker instance
    always
  and I think "on first connect" should be the default.  Basically, if
  there is any chance the config has changed, we don't want old
  subscriptions.

I'm curious what people think, other than ENOPATCH.