Searching for users sometimes appears not to work properly.

[AmandineLP]

I want to start a chat with benoit, we're both in the team internal room, but when clicking Start chat and searching for 'benoit' he doesn't appear in the results

[ara4n]

relatedly, icons seem to be missing entirely from search results too. plus I also couldn't find stevio earlier.

[ara4n]

this is precisely the sort of regression that i think we should be prioritising fixes for rather than letting it overflow into future sprints...

[t3chguy]

It seems to work for me so could you verify whether it still occurs for you @AmandineLP

[dbkr]

I also can't repro this (ie. he appears for me)

[lampholder]

I've heard a bunch of anecdotal reports of users not turning up in search results (whereby search == invite user dialogue).

There are a few ingredients to this problem, including:

• the not-always-obvious rules about when users are supposed to turn up in search results
• the varying settings server to server
• federation
• confusing ux (whereby riot 'completes' a pill even if it hasn't actually found a user if the mxid is valid)
• nondeterministic behaviour (searching sometimes yields different results for two searchs in succession)

[lampholder]

First up - what is the behaviour meant to be? Forgetting for a moment about the UX - who should come back in search results when you search?

I think it is something like:

• if homeserver.com's homeserver.yaml contains user-directory: search_all_users: true and othershomeserver.com's homeserver.yaml contains user-directory: search_all_users: false:
  • when @ bob:homeserver.com searches, he should see:
    • all the users on homeserver.com
    • users on otherhomeserver.com with whom he has ever shared a room
  • when @ alice:otherhomeserver.com searches, she should see
    • only users on homeserver.com and otherhomeserver.com with whom she has ever shared a room

What part do public rooms play in the above? @ara4n ?

[lampholder]

EDIT: UX thread extracted to https://github.com/vector-im/riot-web/issues/7373

[lampholder]

Right, I'm going to break this issue in two. This issue will represent 'inviting is broken'. I'll make a separate issue for 'invite UX is confusing'.

Some useful conversation from #6970 which I've killed off for simplicity:

[ara4n]

First up - what is the behaviour meant to be? Forgetting for a moment about the UX - who should come back in search results when you search?

If your server has search_all_users: false (the default), search results should return:

• Users who you share a room with.
• Users who are in public rooms.

If search_all_users: true, search results should return:

• All users known to your server (i.e. local & remote users which participate in a room which exists on that server)

The directory is maintained only by your local server, and does not interact with the directories maintained by other servers (which are not exposed over federation).

There seem to be two separate bugs here:

• I can't find some users at all on the matrix.org directory (e.g. @nadonomy:matrix.org and benoit here)
• Users often appear in the invite results with a missing profile (e.g. @bwindels:matrix.org in bruno (@bwindels:matrix.org) has no profile in the matrix.org user directory #6970).

My theory is that synapse is failing to keep the user directory maintained correctly... and Riot is failing to sometimes provide the right profile info (given this is certainly an intermittent bug).

[turt2live]

Author's note: This comment is just a research notes dump to hopefully help track down possible problems here.

---

Riot is failing to sometimes provide the right profile info

This sounds like a symptom of synapse not knowing entirely what to return, given I would expect Riot to just use the profile info returned from the search results. Unless Riot does something weird, in which case it probably shouldn't. Profiles being broken sounds a bit like matrix-org/synapse#3310

Because this issue is most prominent on matrix.org (which might be a symptom of the user count) and matrix.org uses workers, I'm tempted to blame matrix-org/synapse#3714 to a degree. matrix-org/synapse#3631 might also be related, although that doesn't appear to be the case in this issue.

The directory being unstable appears to be hinted at by matrix-org/synapse#2306

[turt2live]

also for information gathering purposes: matrix.org uses update_user_directory: false (because worker) and search_all_users: false, implying this might be a race condition (or similar) in synapse, as described by matrix-org/synapse#3714 - although shouldn't the race condition be fixed by update_user_directory: false? (to be continued...)

[turt2live]

more info:

meanwhile, i suspect riot might have a codepath to insert local members in to the user lookup rather than just use the directory
which might explain why it sometimes magically starts working

[turt2live]

I can't seem to replicate the issue locally, but it is easily reproducible on matrix.org:

1. Create 2 accounts and log in to both
2. Create a new room with Account 1
3. Try to invite Account 2 by name only - it should fail to find a result, requiring the full user ID
4. Finish inviting the user and accept the invite on Account 2
5. Create another new room with Account 1
6. Try the same process from step 3, except this time it should give some result - this fails on matrix.org but not with a self-hosted server. I even tried with workers and wasn't able to reproduce the issue.

I suspect this a result of the load matrix.org is under, and I'm not about to spin up a test environment to match the same scale to see if it fails in the same way.

[richvdh]

The user directory was rewritten by matrix-org/synapse#4537 and friends, and I wasn't able to reproduce this on matrix.org, so I think it's fixed.

[CybotTM]

Still have similar problems with web and desktop client - not with new RiotX client.
Seems client is messing with server results - there are just results in the result list missing, which should be there - and correctly appear in RiotX client search results.

[t3chguy]

Please make a new issue with some usable information so this can be investigated, results from both, can be anonymized, ideally API responses from the network tab etc