REST endpoint Connections total incorrect paused status

Syncthing macOS uses the pause and resume endpoints to manage the connections in one go. But for some reason all connections are paused but the total.paused returns false. This is not what I expect. See webgui chrome JSON trace.

paused there is false for the same reason that address and crypto are the empty string, etc. They are not fields that are filled out for the total, yet they are present in the type used in the reply. Arguably thatā€™s a bug and a different type should be used.

This snippet makes more sense now how it works. I was misled by the name ā€˜totalā€™. But is only to have total In and Out bytes, it would not be hard to calculate the total paused state for this total connection. Which in my opinion adds extra functionality to this entry. Currently the total paused state is calculated in-application.

So what would you expect as the ā€œtotal paused stateā€? True if any remote device is paused or if all remote devices are paused?

Same goes for connected, Iā€™d assume we say connected as soon as one connection is active. Or should we just remove all these unpopulated members?

Iā€™ve opened API: /rest/system/connections has misleading "total" entries Ā· Issue #8103 Ā· syncthing/syncthing Ā· GitHub to track this, but letā€™s keep the discussion about it here for now.

2 Likes

I would prefer total.paused = true if all remote devices are paused. For total.connected = true the same story (all devices). And if we agree on this we should document its behaviour. Itā€™s also a matter of taste which thing we decide. Having a total connection in the connection list is still a special purpose entry not exposed on a different endpoint.

The main point of the total entry is to give the total traffic counters, which doesnā€™t reset when connections come and go. So this is functionality that canā€™t be recreated by just summarizing the other connection entries. Same canā€™t be said for paused and such.

I agree, the extra info is easily reproducible and the semantics would be ambiguous. Letā€™s just remove the fields.

I totally agree on you both, we should indeed remove those fields for the total entry and document it slightly a little better what the purpose of the total entry is.

For the application we will derive the all/any paused state by ourselves which is no problem at all.

Thanks for the good discussion.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.