I didn't mean to press submit that quickly.

So yeah, it announces $conn.object_path/Group/i channels twice because both groups_created and set_list_received emit NewChannels for them.

I've attached a patch which fixes the problem but it feels clunky. What do you think?

(In reply to comment #1)
> So yeah, it announces $conn.object_path/Group/i channels twice because both
> groups_created and set_list_received emit NewChannels for them.

I was about to ask why set_list_received needs to emit NewChannels at all. It looks as though my goal was probably to signal the creation of the channels with their members already present, rather than signal them empty and then add all the members afterwards.

If this has never actually worked, because tp_base_contact_list_groups_created signals the channels' creation, then we might as well just drop the tp_base_contact_list_announce_channel calls from set_list_received?

(Rationale for accepting this less-than-ideal behaviour: any legacy apps that are broken by it are already broken, and non-legacy apps shouldn't be using these channels anyway.)

Created attachment 72438 [details] [review]
tp_base_contact_list_set_list_received: don't re-announce groups

We already announced each group from tp_base_contact_list_groups_created
a few lines ago; we don't need to do it again.
    
Ideally we'd add each channel's members before announcing the
channel itself, so that the channel is created "fully-formed"; but
we've never actually done that, and keeping the first NewChannels
instead of the second seems less likely to break applications.
These channels are only for legacy code anyway: any modern client
should be using the ContactGroups interface.

---

Here's my suggestion for how to fix this. Thoughts?

I've verified with dbus-monitor that test-contact-lists creates each group once; currently adding a regression test, just to make sure.

Created attachment 72442 [details] [review]
contact-lists test: add a regression test for fd.o #52011

that looks correct to me. +1

Fixed in git for 0.20.3, 0.21.1. Thanks!