Can we avoid directly awaiting here? This approach leads to blocking the rest of execution, but instead we could start the Promise and await it where initialNavInfo is needed, eg. fetchEntryInfos and setNewSession which both need calendarQuery, and of course navInfoPromise itself.

Interesting!! Looks like this code was intentionally introduced in D4465.

Are you sure it needs to be removed? If the user ID isn't in Redux, we won't be able to show them in the UI, right?

From the inline comments in D4465:

What is the scenario in which this effect is needed?

When user enter manually IDs into URL (like http://localhost/comm/chat/thread/new/84072,83850,99999) and some of them are not in userStore.

This is handled by this diff. It's not possible to enter IDs that are not in the userStore from the UI. (this is changed in the next diff, but it's handled there correctly)

Even if the code in website-responders.js is broken the UI will be correct. The ids from navInfo are assigned to the selectedUserIDs but then they are immediately filtered using data in the userStore:

const selectedUserIDs = useSelector(state => state.navInfo.selectedUserList);
const otherUserInfos = useSelector(userInfoSelectorForPotentialMembers);
const userInfoInputArray: $ReadOnlyArray<AccountUserInfo> = React.useMemo(
    () => selectedUserIDs?.map(id => otherUserInfos[id]).filter(Boolean) ?? [],
    [otherUserInfos, selectedUserIDs],
);

And selectedUserIDs isn't used anywhere else (later we only use userInfoInputArray, which contains only users that are in the userStore).

The only thing that's changed by removal of this fragment of code is that the URL won't be updated on page load, but only when user tries to add/remove someone in the chat composer.

But it's going to be changed in the next diff anyway (where the mentioned change will be handled correctly) so I'm going to revert this deletion here.

Do we really need to create this relationship? It means that any user can fill up another user's userStore just by constructing URLs. Can we avoid this issue somehow?

Ignore this, I think I can tell what's going on now...

It means that any user can fill up another user's userStore just by constructing URLs

This should add only a relationship between the current user and some other user (and not between any pair of users). Currently the same can be achieved by just blocking/ sending a friend request to someone. So I can't see how you could fill up someone else's userStore?

Do we really need to create this relationship?

I assumed that we need to keep in sync relationships on keyserver and userStore (you have someone in userStore <=> you have at least a KNOW_OF relationship). If we don't we could just append userInfos from the URL.

If we continue with this approach do you think I should add a comment or use then? Or is it clear enough?

If we don't we could just append userInfos from the URL.

I think that would be the best approach in this case. I don't think we need to permanently create this relationship... on the other hand, blocking/sending a friend request requires some permanent data storage on the client.

(Good point that friend request has a similar effect, though...)

No, if we continue with this approach honestly your code is fine. I was just not reading thoroughly enough – this is my bad.