-
Notifications
You must be signed in to change notification settings - Fork 29
Open
Description
This is from a comment in membershipResolver.test.ts:
sometimes (50% of the time?) when we eliminate duplicate ADD_MEMBERs,we're eliminating one that would have needed to have come BEFORE something else, in this case the CHANGE_MEMBER_KEYs action that happens after that person is admitted. Here's an example of a bad graph that you can end up with that way:
๐ฉ๐พ ROOT
ADD_MEMBER:๐จโ๐ฆฒ
<== ADD_MEMBER:๐ณ๐ฝโโ๏ธ was removed from here
INVITE:kPFx4gwGpuWplwa
INVITE:tiKXBLLdMbDndJE
ADMIT:๐ณ๐ฝโโ๏ธ
CHANGE_MEMBER_KEYS:{"type":"MEMBER","name":"๐ณ๐ฝโโ๏ธ",...} <== we can't do this because ๐ณ๐ฝโโ๏ธ hasn't been added yet
ADD_DEVICE:๐ณ๐ฝโโ๏ธ:laptop
ADD_MEMBER:๐ณ๐ฝโโ๏ธ
INVITE:dQRE52A+7UGr8X9
ADD_MEMBER:๐ด
INVITE:j6cC8ZyjyhuojZw
ADMIT:๐ด
CHANGE_MEMBER_KEYS:{"type":"MEMBER","name":"๐ด",...}
ADD_DEVICE:๐ด:laptop
Here's how that graph should have been resolved:
๐ฉ๐พ ROOT
ADD_MEMBER:๐จโ๐ฆฒ
ADD_MEMBER:๐ณ๐ฝโโ๏ธ <== in the bad graph,this ADD_MEMBER was discarded as a duplicate
INVITE:fNpSg0uBcW1vYvf
ADD_MEMBER:๐ด
INVITE:PkD7SISvUt/3YlJ
ADMIT:๐ณ๐ฝโโ๏ธ
CHANGE_MEMBER_KEYS:{"type":"MEMBER","name":"๐ณ๐ฝโโ๏ธ",...}
ADD_DEVICE:๐ณ๐ฝโโ๏ธ:laptop
<== ADD_MEMBER:๐ณ๐ฝโโ๏ธ was removed from here
INVITE:Pu6NaY6HfbITAf6
INVITE:7vVS0NXz+u15Mx2
ADMIT:๐ด
CHANGE_MEMBER_KEYS:{"type":"MEMBER","name":"๐ด",...}
ADD_DEVICE:๐ด:laptop
Metadata
Metadata
Assignees
Labels
No labels