Page MenuHomePhabricator

[lib] fix @-mentioning in a pending GENESIS sidebar crashes app
ClosedPublic

Authored by ginsu on Feb 5 2024, 2:01 PM.
Tags
None
Referenced Files
F2160885: D10956.id36747.diff
Mon, Jul 1, 10:09 AM
Unknown Object (File)
Sun, Jun 30, 4:19 AM
Unknown Object (File)
Sun, Jun 30, 1:26 AM
Unknown Object (File)
Sat, Jun 29, 7:10 PM
Unknown Object (File)
Thu, Jun 27, 9:19 PM
Unknown Object (File)
Tue, Jun 25, 11:06 AM
Unknown Object (File)
Mon, Jun 24, 3:32 PM
Unknown Object (File)
Fri, Jun 21, 12:44 AM
Subscribers

Details

Summary

@-mentioning in a pending GENSIS sidebar would crash the app. This was because in useMentionTypeaheadChatSuggestions we were attempting to get the chat mention search index from the communityThreadIDForGenesisThreads with a pending thread info id. The reason this is an issue is that we build the communityThreadIDForGenesisThreads is built with resolvedThreadInfos. This meant that pending sidebar thread ids (which look like this pending/sidebar/256|145027) weren't included in the communityThreadIDForGenesisThreads object, and was returning an undefined chatSearchIndex.

The solution I've come up with is to add a check if the thread is pending and then if it is, use the resolved containing threadID of the pending sidebar since that will have the same chat mention candidates as the sidebar thread if it was resolved.

Linear task: https://linear.app/comm/issue/ENG-6640/mentioning-a-user-in-a-pending-genesis-sidebar-causes-the-app-to-crash

Test Plan

Please see the demo video below

Here are the @ mentioning candidates for a resolved sidebar:

Here are the @ mentioning candidates for a pending sidebar:

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ginsu added reviewers: atul, inka.
ginsu requested review of this revision.Feb 5 2024, 2:19 PM
ginsu edited the test plan for this revision. (Show Details)
ginsu edited the summary of this revision. (Show Details)
ginsu retitled this revision from [web] fix @-mentioning in a pending GENESIS sidebar crashes app to [lib] fix @-mentioning in a pending GENESIS sidebar crashes app.Feb 5 2024, 2:54 PM
ashoat requested changes to this revision.EditedFeb 5 2024, 6:17 PM

use the resolved containing threadID of the pending sidebar since that will have the same chat mention candidates as the sidebar thread if it was resolved

This makes sense, but it's working confirming that pending sidebars are the only kind of pending threads where this can happen.

I think we can also have pending threads that are channels of GENESIS. Will this change behavior in that case? If so, is that change what we want?

(Looks like this is addressed in the next diff in the stack)

lib/components/chat-mention-provider.react.js
44 ↗(On Diff #36656)

Would it be better to fix communityThreadIDForGenesisThreads to make it impossible to make this mistake?

For instance, imagine communityThreadIDForGenesisThreads was a function that took a ThreadInfo. Then the check you're doing could be made inside of it.

This revision now requires changes to proceed.Feb 5 2024, 6:17 PM

make getCommunityThreadIDForGenesisThreads type read only

lib/components/chat-mention-provider.react.js
217–219 ↗(On Diff #36747)

This was being returned, but not used...

ashoat added inline comments.
lib/components/chat-mention-provider.react.js
235–238 ↗(On Diff #36747)

Wondering why you replaced the ternary expression with this. In general I think avoiding the use of let in favor of const is good practice, but maybe the ternary expression was getting formatted poorly?

This revision is now accepted and ready to land.Feb 7 2024, 10:57 AM
lib/components/chat-mention-provider.react.js
235–238 ↗(On Diff #36747)

Personally I thought this was easier to read, but happy to change it back a ternary expression + use const if that is better practice

lib/components/chat-mention-provider.react.js
235–238 ↗(On Diff #36747)

Yeah I think that would be better, unless it breaks one of the rules here

This revision was landed with ongoing or failed builds.Feb 7 2024, 11:11 AM
This revision was automatically updated to reflect the committed changes.