Ticket #10308 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

When owner leaves, shared activity does not always go away on his own view (link-local)

Reported by: erikos Owned by: erikos
Priority: normal Milestone: 10.1.3
Component: presence-service Version: Development build as of this date
Keywords: Cc:
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking:

Description

Upstream bug at SL: http://bugs.sugarlabs.org/ticket/2192 (has as well a tracking down of the issue).

Steps to reproduce:

- A: Share activity

- B: Join

- B: Leave activity

---> both neighborhood views are updated correctly (buddy leaves)

- A: Stop shared activity

---> activity goes not away from A's neighborhood view, but goes away from B's


Follow up test:

- A: share another activity

- B: join

---> on A the old shared activity goes away

Change History

Changed 4 years ago by erikos

  • summary changed from When owner leaves, shared activity does not always go away on his own view to When owner leaves, shared activity does not always go away on his own view (link-local)

Seems to be a link local issue "only".

Changed 4 years ago by Quozl

  • milestone changed from Not Triaged to 10.1.3

Reproduced easily.

This was previously reported here #9545 (icons persist in Neighborhood View after resources gone), #9560 (os33 - Neighborhood View unreliable), and possibly #9619 (Network View unstable after quitting shared chat activity) but had not been investigated to the level of detail of SL 2192. Good to see more focus on it.

Changed 4 years ago by erikos

  • next_action changed from code to review
diff --git a/src/activity.py b/src/activity.py
index 29ba1a5..6c5825c 100644
--- a/src/activity.py
+++ b/src/activity.py
@@ -1143,6 +1143,7 @@ class Activity(ExportedGObject):
         # we've joined.
         if self._joined:
             self._remove_buddies(removed_buddies)
+            self._claimed_buddies -= removed_buddies
 
         # if we were among those removed, we'll have to start believing
         # the spoofable PEP-based activity tracking again.

Looks like the fix is as "simple" as that. Testes for Salut and verified that it does not break anything on Gabble. (Mind that due to salut vs collaboration there might be occasions where we still see leftover sharing activities on some neighborhood views. To be 100% where the issue might be we need to first test with idle suspend disabled)

Changed 4 years ago by erikos

  • next_action changed from review to package

Changed 4 years ago by erikos

  • next_action changed from package to test in build

Did land in 351.

Changed 4 years ago by greenfeld

  • status changed from new to closed
  • next_action changed from test in build to no action
  • resolution set to fixed

Verified that we no longer see the closed activity after following the reproduction steps above in 10.1.3 os352 with ad-hoc, AP-based salut, and mesh networks on both XO 1 & 1.5 machines (as appropriate).

Changed 4 years ago by garycmartin

Not sure if this should be a new ticket, but the reverse of this test case is still leaving the activity icon behind on the initiators neighbourhood view:

- A: Share activity

- B: Join

- A: Stop shared activity

- B: Stop shared activity

---> activity icon is left on A's neighbourhood view

Note: See TracTickets for help on using tickets.