https://gitlab.synchro.net/main/sbbs/-/merge_requests/320#note_3826

This change worked fine for me on Linux, but is causing a recycle loop for the Services now that I have put the new EXEs in place on Windows. The loop eventually stops on its own, sometimes after as few as 3 recycles, but sometimes as many as 19 recycles.

After comparing my Linux to Windows setup I saw the Publish QOS was different between the two, with 0 At most once on Linux and 1 At least once on Windows. Swapping values so Windows is 0 and Linux is 1 confirms that this setting is involved in the problem (Windows stops recycle looping, Linux starts recycle looping, and on Linux all servers are affected not just Services).

I guess the issue is that with "1 At least once" set as the Publish QOS, sometimes the mqtt_pub_noval() call on [line 485](https://gitlab.synchro.net/main/sbbs/-/blob/81d4575ee5e6ffc93a0678fec3373de8065ad620/src/sbbs3/mqtt.c#L485) is then being received by the subscription setup on [line 487](https://gitlab.synchro.net/main/sbbs/-/blob/81d4575ee5e6ffc93a0678fec3373de8065ad620/src/sbbs3/mqtt.c#L487), and the system sees that as a request to recycle.

I assume line 485 is meant to be a notification telling clients "this server has recycled"? And in that case, maybe the key should be renamed from "recycle" to "recycled" so then it doesn't get captured by the subscription as an instruction to recycle?

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/320#note_3832

No, that is not a notification telling clients "this server has recycled".

If I remember correctly, the publishes to the "recycle" topic were necessary to reset the server/services recycle semaphore timestamp upon initial bring-up. Something like that.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/320#note_3833

Ahh, bad assumption on my part then!

So in hindsight, maybe these two lines should have stayed in mqtt_startup, since it's only the subscriptions that need to be re-applied in the connect callback when a reconnect occurs:

mqtt_pub_noval(mqtt, TOPIC_SERVER, "recycle");
mqtt_pub_noval(mqtt, TOPIC_SERVER, "client");

I just tested that here, and my Linux build no longer hits a recycle loop even with the Publish QOS set to 1.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net