Better handle disconnects, e.g. after changing theme

[mojo-jojo-7]

Relevant components

• [x] Standalone tray application (based on Qt Widgets)
• [ ] Plasmoid/applet for Plasma desktop
• [ ] Dolphin integration
• [ ] Command line tool (syncthingctl)
• [ ] Integrated Syncthing instance (libsyncthing)
• [ ] Backend libraries

Environment and versions

• Versions of syncthingtray, qtutilities and c++utilities: 1.5.2, ?, ?
• Qt version: 6.6.3
• C++ compiler (name and version): ?
• C++ standard library (name and version): ?
• Operating system (name and version): Windows 10 Pro 22H2

Bug description The tray app disconnects from Syncthing when I change the theme and click on "Save" using the Web GUI. And although it connects back automatically after some time, this seems weird.

Steps to reproduce

1. Make sure Syncthing Tray is connected and running
2. Open the Web GUI > Actions > Settings > GUI > Change theme > Save
3. Notice the tray app disconnecting with the error: "Unable to request disk events. Connection closed" or "Unable to request device statistics. Connection closed"

Expected behavior No disconnection should happen

[Martchus]

Probably Syncthing itself really just restarted its listener. In this case it is natural for Syncthing Tray to consider this a disconnect. Since Syncthing Tray cannot know the reason for the disconnect it cannot really filter this kind of error out. Not sure what I can improve here from my side.

[Martchus]

I could add a feature to suppress errors if it is possible to reconnect within a certain timeframe (but not sure whether it's worth it).

[mojo-jojo-7]

Thanks for the quick response @Martchus. I flagged because I wasn't sure what was happening, but if it is what you suspect it is, then that indeed doesn't sound worth it. Feel free to close the issue!

[Martchus]

I was actually able to reproduce the problem yesterday - also under Windows 10. I noticed some additional particularities that were a bit strange:

1. The disconnect was not immediate (but happened and the error was "Connection closed"). Probably the connection was not terminated immediately by Syncthing and only closed after the long-polling timeout was exceeded. This will probably not affect the feature idea mentioned in https://github.com/Martchus/syncthingtray/issues/257#issuecomment-2081551333.
2. The configured re-connect interval was not effective; no re-connect happened. Triggering a re-connect manually by clicking the button in the settings worked immediately, though. Maybe I was finally able to reproduce https://github.com/Martchus/syncthingtray/issues/217.

I've just tested under GNU/Linux as well. There the behavior is different and actually more like I would expect it:

1. The disconnect was immediate (with error "Connection refused").
2. The re-connect interval was effective.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Martchus]

Basically the same as https://github.com/Martchus/syncthingtray/issues/236.