Skip to content

Handle unknown users everywhere #716

Open
0 of 1 issue completed
Open
0 of 1 issue completed
@gnprice

Description

@gnprice

Our local store has a map with all the users we know about, in PerAccountStore.users aka store.users. But this might not be all the users in the realm. In particular, if the self-user is a guest user, there may be users we don't have permission to know about.

For the most part the users we actually encounter will be users we do have data on: for example, a guest user still has permission to know about users that are subscribed to any of the same streams they are, which means that most of the messages they see there will be sent by users they know about. But there could be older messages by users who've since unsubscribed, and other scenarios. So we will sometimes encounter a user ID that doesn't exist in store.users.

We should therefore make sure we never crash when we encounter a user that's not in store.users. This means:

  • When we look up a user with an expression like store.users[userId], we should explicitly handle the possibility that the result is null.

    This means no ! and no assert saying it's non-null. Depending on the context, the code might use ?. and ?? to fall back to a placeholder like ZulipLocalizations.unknownUserName, or might return without doing anything, or something else as appropriate.

    • The exception is that it's fine to assume the self-user is present. We have a few places that do this; they could benefit from being factored out into a small getter like store.selfUser.
  • When we have a context like a Message that provides its own details on a user (like the message sender), we should fall back to those if the user is unknown. That way we not only don't crash, but provide helpful information, in cases like a guest user looking at older messages sent by someone no longer subscribed to their streams.

We already do these correctly in many places, but there are several places we don't. So this task is about sweeping through those, probably in one commit per call site, and fixing them.

A key part of doing this is to find an exhaustive list of places that are potentially affected. You can do this in an IDE by going to the definition of PerAccountStore.users and then using the "find references" feature.

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    a-modelImplementing our data model (PerAccountStore, etc.)help wanted

    Type

    No type

    Projects

    Status

    No status

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions