Page MenuHomePhabricator

[lib] Consider thread infos in useUsersSupportThickThreads()
Needs ReviewPublic

Authored by angelika on Thu, Nov 14, 12:50 PM.

Details

Reviewers
tomek
kamil
Summary
Test Plan
  1. Mobile user makes a new thick thread with web user (with new message button)
  2. Mobile user sends friend request
  3. Throw some error in fetchUserIdentitiesPromise() so that finding user indentity always fails and make auxUserInfo empty.
  4. Web user accepts the request
  5. Before a new thin thread was created. Now no new threads are created, users are friends, because there is already a thick thread between users.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Hmmm... I know I initially proposed doing both D13938 and this, but after reading D13938 I wonder if we need this additional mechanism.

@kamil, do you know if it's possible for the user to see a thick thread in the UI if one of the members doesn't pass the userHasDeviceList check? Specifically in this case, I'm wondering about a PERSONAL thread, like in @tomek's original report in ENG-9509. It seems to me that the thread creation message would have had to come in from an established Olm session, so I would expect that userHasDeviceList would always be true, and the check in D13938 would suffice.

If that's the case, I'd prefer to keep the code simple. Sorry for any misdirection here!

lib/shared/thread-utils.js
1903–1907

What do you think of this notation?