Verify membership when test if name is ambiguous

[multisme]

Verify if the membership is not Leave when checking if a name in a room is ambiguous.

Signed-off-by:
multi

Fix #5774

[multisme]

It's pretty straightforward but should I had some tests?

[codecov]

Codecov Report

❌ Patch coverage is 98.79518% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 88.46%. Comparing base (a4e68ba) to head (2892f60).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/matrix-sdk-base/src/room/members.rs	98.79%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5780   +/-   ##
=======================================
  Coverage   88.45%   88.46%           
=======================================
  Files         360      360           
  Lines      100322   100400   +78     
  Branches   100322   100400   +78     
=======================================
+ Hits        88737    88816   +79     
+ Misses       7420     7417    -3     
- Partials     4165     4167    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

CodSpeed Performance Report

Merging #5780 will not alter performance

_{Comparing multisme:fix_check_if_user_really_ambiguous (2892f60) with main (a4e68ba)}

Summary

✅ 50 untouched

[stefanceriu]

So we don't want to disambiguate the name of a left user, why is that? I see the AmbiguityCache has a concept of active members so what are we trying to achieve here?

[multisme]

It's because of the spec. It only sees member with an join or an invite membership as needing disambiguation

[multisme]

I updated the code to follow more precisely the spec.

[bnjbvr]

Thanks for the patch! Can you add a test please? Ideally it would show the case that's failing on main (but supposed to work), and that would be working with your patch now.

[bnjbvr]

Can you write the second part with a match statement, please? This will make it so that we explicitly handle all the membership cases, and we don't forget to think about handling it, would we have a new membership kind later on.

if !is_display_name_ambiguous(&display_name, s) {
  return false;
}

match *membership {
 // handle all variants explicitly here
}

[multisme]

Ok I will

[multisme]

@bnjbvr
I have a problem here. There is a test that is failing that should be failing

matrix-rust-sdk/crates/matrix-sdk-base/src/room/members.rs

Lines 615 to 622 in 7a93c57

	assert_eq!(room.get_member(me).await.unwrap().expect("Me user").display_name(), Some("Me"));
	assert_eq!(
	room.get_member(mewto).await.unwrap().expect("Mewto user").display_name(),
	Some("Me")
	);
	assert!(room.get_member(me).await.unwrap().expect("Me user").name_ambiguous());
	assert!(room.get_member(mewto).await.unwrap().expect("Mewto user").name_ambiguous());

Unless I misunderstood, the name should be here ambiguous and the test should on line 621 should not be failing. Should I make a new issue ?

[bnjbvr]

It sounds like the code you've changed introduced a regression, so, no, we can't merge this as is and open a new issue. Instead, one should investigate the issue and attempt to fix it :)

[multisme]

So i checked, and it seems that when using saving_changes to store the member events in MemoryStore, the HashMap display_names: HashMap<OwnedRoomId, HashMap<DisplayName, BTreeSet<OwnedUserId>>> is never updated unless you expressly do it. But this is the Hashmap used by is_the_display_name_ambiguous.
If this is not the behavior expected, I can make an issue and a PR for making sure that hashmap is populated, wait for it to get merged, and then finish this PR.

[multisme]

@bnjbvr
So i checked, and it seems that when using saving_changes to store the member events in MemoryStore, the HashMap display_names: HashMap<OwnedRoomId, HashMap<DisplayName, BTreeSet<OwnedUserId>>> is never updated unless you expressly do it. But this is the Hashmap used by is_the_display_name_ambiguous.
If this is not the behavior expected, I can make an issue and a PR for making sure that hashmap is populated, wait for it to get merged, and then finish this PR.

[multisme]

I made a mistake anyway, I should check the membership of every RoomMember with the same displayname, I'm getting back into IT.