[Ready for payment - $1000] mWeb- Chat- In secondary device, in real time, emoji selected is not updated in frequently used

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

Pre- con: In 2 device, open same account, same conversation, open emoji picker

1. Go to https://staging.new.expensify.com/
2. Tap on a conversation as mentioned in one condition
3. Tap on emoji picker
4. Select emoji which is not in frequently used
5. Tap emoji picker again to see selected emoji in frequently used
6. Notice the same conversation and emoji picker opened in secondary device

Expected Result:

In secondary device, in real time, emoji selected must be updated in frequently used list.

Actual Result:

In secondary device, in real time, emoji selected is not updated in frequently used list.

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.47.3
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Bug6144776_redmi.mp4

Bug6144776_samsung2nd_device.mp4

Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~017543882e0e6eca1f
• Upwork Job ID: 1685003669049524224
• Last Price Increase: 2023-07-28

[melvin-bot]

Triggered auto assignment to @lschurr (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[huzaifa-99]

Proposal

Please re-state the problem that we are trying to solve in this issue.

We want the frequently used emojis to be updated in real-time on secondary devices.

What is the root cause of that problem?

When are not updating the already rendered frequently used emojis in device B when we update frequently used emojis in device A.

What changes do you think we should make in order to solve the problem?

We can listen to ONYXKEYS.FREQUENTLY_USED_EMOJIS and based on that update frequently used emojis.

What alternative solutions did you explore? (Optional)

N/A

[hoangzinh]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Chat- In secondary device, in real time, emoji selected is not updated in frequently used

What is the root cause of that problem?

From the log, I found that BE already sent pusher event to secondary device about frequentlyUsedEmojis

But unfortunately, in EmojiPickerMenu component, we just pick up frequentlyUsedEmojis in initializer function of component

App/src/components/EmojiPicker/EmojiPickerMenu/index.js

Lines 60 to 72 in 7754c7a

	this.emojis =
	getOperatingSystem() === CONST.OS.WINDOWS
	? EmojiUtils.mergeEmojisWithFrequentlyUsedEmojis(emojis.slice(0, flagHeaderIndex))
	: EmojiUtils.mergeEmojisWithFrequentlyUsedEmojis(emojis);
	// Get the header emojis along with the code, index and icon.
	// index is the actual header index starting at the first emoji and counting each one
	this.headerEmojis = EmojiUtils.getHeaderEmojis(this.emojis);
	// This is the indices of each header's Row
	// The positions are static, and are calculated as index/numColumns (8 in our case)
	// This is because each row of 8 emojis counts as one index to the flatlist
	this.headerRowIndices = _.map(this.headerEmojis, (headerEmoji) => Math.floor(headerEmoji.index / CONST.EMOJI_NUM_PER_ROW));

When the frequentlyUsedEmojis is updated, we haven't had any logic to update states filteredEmojis and headerIndices yet.

What changes do you think we should make in order to solve the problem?

1. We need to include ONYXKEYS.FREQUENTLY_USED_EMOJIS into withOnyx HOC => It will inform component to updates when this data in Onyx is updated
2. In componentDidUpdate of EmojiPickerMenu component, we need to check if the props.frequentlyUsedEmojis is updated, we need to recompute the states filteredEmojis and headerIndices like the this in the initializer here

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~017543882e0e6eca1f

[melvin-bot]

Current assignee @lschurr is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @robertKozik (External)

[AdeemWaseem]

Contributor details
Your Expensify account email: adeemwaseemmalik92@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01d2b054d1769064c3

Issue:

The issue is that the app crashes when navigating to the /details page directly from the /expenses page.

Proposal:

The following changes will be made to fix the issue:

The /details page will be made to load asynchronously. This will prevent the app from crashing if the page takes a long time to load.
The /details page will be made to check for the existence of the expense before loading. This will prevent the app from crashing if the expense does not exist.
The /details page will be made to handle errors more gracefully. This will prevent the app from crashing if an error occurs while loading the page.
Steps to implement the proposal:

Create a fork of the Expensify/App GitHub repo.
Create a branch on the fork and make the changes outlined in the proposal.
Test the changes on all platforms.
Create a pull request to merge the changes into the main repository.
Expected results:

The app will no longer crash when navigating to the /details page directly from the /expenses page.

[melvin-bot]

📣 @AdeemWaseem! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
2. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
3. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[robertKozik]

Hi! Thank you all for the proposals!

@AdeemWaseem I think you confused the issues as your proposal is not connected to the issue at all, also your comment does not follow the proposal template

@hoangzinh and @huzaifa-99 both of your proposals addressed the root cause of the problem correctly, as we are not listening to frequentlyUsedEmojis key at all. The solutions are also similar, so we would probably go with the faster proposal.

selected proposal: Proposal
author of proposal: @huzaifa-99

🎀 👀 🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @puneetlath, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[huzaifa-99]

Thank you for the review @robertKozik. Waiting for assignment to start the pr

[hoangzinh]

@robertKozik I feel it's not fair to me although @huzaifa-99 is first.
Take a look at @huzaifa-99 proposal #23800 (comment) and my proposal here #23800 (comment)

• We submitted almost same time, just different in seconds.
• The reason I lated submitting proposal comparing with @huzaifa-99 in few seconds because I need to prepare my proposal carefully with details in RCA and solutions as well (It's hard to detect in other case, but in this case, in my opinion, we're hard to get the RC if we read @huzaifa-99 RCA, also his solution is argue to me, one again, it's just my opinion).

=> They are reason why I feel it's not fair to me.

[robertKozik]

Thank you for your insights. Indeed, I missed that there were only seconds between both proposals, but in such cases, we need to somehow choose between one and another.
I see your point, as I'm studying your RCA provides more insights on a problem but can be summed up to your last sentence there: When the frequentlyUsedEmojis is updated, we haven't had any logic to update states filteredEmojis and headerIndices yet, which is also stated in @huzaifa-99 RCA only without the specific methods/variables names.

In my eyes, your proposal is a more detailed version of the first one, so I'm not sure I can count this as a new proposal. But as we have now CME @puneetlath here, let's wait for his input on this.

@puneetlath, what do you think about this situation?

[huzaifa-99]

@robertKozik We are already listening to ONYXKEYS.FREQUENTLY_USED_EMOJIS in EmojiUtils, which is what updates the frequently used emojis in onyx, so I think the point about the server sending pusher event for ONYXKEYS.FREQUENTLY_USED_EMOJIS is very obvious and is not new information.

About updating the component state to reflect that updated onyx state, its again obvious that if the component state based on an onyx key is not updating, then we are not properly listening to onyx key changes.

I don't think there is any new information in this proposal but i will go ahead with @robertKozik and @puneetlath suggestion. Again thanks for the review

[puneetlath]

Just catching up on the discussion, but I agree there's no clear answer and we have to make a decision in some way. @huzaifa-99 does have a more high-level proposal and @hoangzinh's is more detailed, but I think the concepts covered in the proposals are well-known, so the high-level proposal is enough to understand what will be done in this scenario. So I'm good with @robertKozik's decision to go with @huzaifa-99's proposal since it was first.

Thanks for your contributions and proposals everyone!

[melvin-bot]

📣 @huzaifa-99 You have been assigned to this job!
Please apply to the Upwork job and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Once you apply to this job, your Upwork ID will be stored and you will be automatically hired for future jobs!
Keep in mind: Code of Conduct | Contributing 📖

[huzaifa-99]

Pr will be ready shortly, thanks for the assignment

[huzaifa-99]

@robertKozik @puneetlath PR #23965 is ready for review.

[melvin-bot]

🎯 ⚡️ Woah @robertKozik / @huzaifa-99, great job pushing this forwards! ⚡️

The pull request got merged within 3 working days of assignment, so this job is eligible for a 50% #urgency bonus 🎉

• when @huzaifa-99 got assigned: 2023-07-31 19:42:45 Z
• when the PR got merged: 2023-08-02 23:39:29 UTC

On to the next one 🚀

[huzaifa-99]

I think this got deployed to prod, right?

cc: @puneetlath

[lschurr]

Ah, yeah this looks like one where the automation didn't work correctly. Let me add the checklist.

[lschurr]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@robertKozik] The PR that introduced the bug has been identified. Link to the PR:
• [@robertKozik] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@robertKozik] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@robertKozik] Determine if we should create a regression test for this bug.
• [@robertKozik] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@lschurr] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[lschurr]

@robertKozik could you work through the checklist to confirm whether we need a regression test here?

[lschurr]

This should have been paid last week, so we can go ahead and issue payments.

Payment summary:

• Bug reporter: Applause - no payment
• Contributor: @huzaifa-99 $1500
• Contributor+: @robertKozik - no payment

[huzaifa-99]

@lschurr Actually I was the Contributer for this issue, can you please update the payment summary? Thank you

[hungvu193]

Yeah I think I was tagged accidentally 😂

[lschurr]

Ooops! Typed an h and let GH do it's thing. Fixing!

[lschurr]

@robertKozik @huzaifa-99 - could you apply for the job? https://www.upwork.com/jobs/~017543882e0e6eca1f

[robertKozik]

@lschurr Actually I'm from Software Mansion (expert agency) so I'm not eligible for payment

[huzaifa-99]

Applied @lschurr. Thank you!

[robertKozik]

[@robertKozik] The PR that introduced the bug has been identified. Link to the PR: I don't think that there is any one particular PR which introduced this
[@robertKozik] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N/A
[@robertKozik] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
[@robertKozik] Determine if we should create a regression test for this bug. I think it's worth to add the test for this as it can be often forgotten to test the interactions between two devices logged on the same account
[@robertKozik] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again. I propose to use the test case from the PR:

• Log in to 2 devices with the same account (logout and then log in if you are already logged in)
• In both devices, go to any chat and open the emoji picker
• From device A select an emoji, and in device B verify the frequently used emojis change (the emoji you used most will be the first in the frequently used list - each emoji has a use counter)
• Repeat step 3 but from device B and verify in device A - frequently used list should be updated correctly

[lschurr]

Great thanks @robertKozik - added a request for that regression test.

Sent offer in Upwork to @huzaifa-99

[huzaifa-99]

Accepted thanks @lschurr

[lschurr]

Payment sent to @huzaifa-99 in Upwork. Closing this one out :)

[lanitochka17]

Issue reproducible on Build 1.3.64-0

Recording.898.mp4

Should I open a new issue or open this one?

[huzaifa-99]

@lanitochka17 Not reproducible for me on v1.3.64-0

Chat.Frequent.Emoji.mp4

---

Sometimes pusher events don't work on already logged-in devices. Can you logout, then log in and try again, please? Thank you!