Subj : src/sbbs3/mqtt.c
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Windows)
Date : Wed Aug 30 2023 18:12:59

https://gitlab.synchro.net/main/sbbs/-/commit/622ffe3dceb089de77078f4d
Modified Files:
	src/sbbs3/mqtt.c
Log Message:
Remove MQTT message publishing from mqtt_connect_callback()A follow-up to commit 81d4575eAlthough I was not able to successfully reproduce the problem that Reereported with his commit (even when changing the SCFG->Networks->MQTT->PublishQOS to 1: At least once) on Windows, I do see how this problem couldtheoretically happen. And like Ree said in the follow-up comment on the MR"maybe these two lines should have stayed in mqtt_startup", they don't reallybelong in the connection callback.The "client" topics only needs to be cleared upon startup or recycle (bypublishing a null message) and it would be bad to clear these topics wheneverthe broker was reconnected (the server's clients didn't magically disconnect).So these "client" topic-clearing publishes are now only done during startup(again).The "recycle" topics don't really need to be published to here at all. Ithink I only did this for cases where someone published a non-null message tothe topic and its stale message would remain afterward, appearing in MQTTbrowsers (like MQTT explorer) long after the server had recycled. The realsolution to this cosmetic issue is to only publish null (0-length) messages tothe "recycle" topics in the first place.
--- SBBSecho 3.20-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.