-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[$500] iOS - Request Money - Searching for specific HT account while using HT account has an odd behavior #30803
Comments
Job added to Upwork: https://www.upwork.com/jobs/~01c1e5f3f5dad45859 |
Triggered auto assignment to @puneetlath ( |
Bug0 Triage Checklist (Main S/O)
|
Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav ( |
ProposalPlease re-state the problem that we are trying to solve in this issue.The account being searched is at the top of the list, but then reappears at the bottom constantly changing avatars. What is the root cause of that problem?It shows an existing account with a specific existing email and it also adds a non-existed account with non-existed email. When we are searching with some text, search input sends a search term for every single character. In every request, it will call this method, this method returns all list options: App/src/pages/iou/steps/MoneyRequstParticipantsPage/MoneyRequestParticipantsSelector.js Lines 111 to 160 in a61572e
If we find a user with a specific email, that user will be added to sections App/src/pages/iou/steps/MoneyRequstParticipantsPage/MoneyRequestParticipantsSelector.js Lines 115 to 124 in a61572e
And if a user does not exist, we add non-existing users into sections as well, App/src/pages/iou/steps/MoneyRequstParticipantsPage/MoneyRequestParticipantsSelector.js Lines 147 to 159 in a61572e
There are 2 possible cases: App/src/pages/iou/steps/MoneyRequstParticipantsPage/MoneyRequestParticipantsSelector.js Lines 147 to 159 in a61572e
CASE 2: USER EXIST App/src/pages/iou/steps/MoneyRequstParticipantsPage/MoneyRequestParticipantsSelector.js Line 124 in a61572e
But, in every single valid email address, it will be a non-existent user: Existed user: Non-existed users with valid emails: That's why the avatar is changing because, for every valid email, for every single character, it will send a request, in every request, the non-exist user(all different user) will be added into sections, in this example, for all characters in this text [xpensifail.co]. The email was so long, so we didn't see it was changing in the row. Please see from this video: What changes do you think we should make in order to solve the problem?
What alternative solutions did you explore? (Optional)Or we can set a limit on email length, so it can't be that long to be out of the screen. In example, 42 character length email: Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job. |
ProposalPlease re-state the problem that we are trying to solve in this issue.In request money participants selector page, the search results keeps getting constantly updated (i.e avatar, search result itself) even after the user has stopped entering the search value. This is the problem we are trying to solve here. What is the root cause of that problem?When a long search text is entered (e.g. [email protected]), this will generate many API requests to the server for reports as shown here. Since each of these responses will come back at some time later and trigger the What changes do you think we should make in order to solve the problem?We can solve this problem by debouncing the updation of chat options thereby saving processing time which will matter a lot in a HT environment.
What alternative solutions did you explore? (Optional) |
@puneetlath, @mananjadhav Whoops! This issue is 2 days overdue. Let's get this updated quick! |
Thoughts on the proposals @mananjadhav? |
Will review this today. |
Current assignee @puneetlath is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new. |
I think it also makes sense to debounce the API calls for this. Would just like a second opinion from @marcaaron since I believe he implemented this. |
API calls happening "too many times"? Not sure I really buy that. There's a debounce for the API calls already. Maybe they happen too many times, but what does it have to do with:
Do we feel like we have a clear understanding of what this bug report is about? |
@marcaaron There is a similar approach used here in |
Backing up, why does the avatar change? It changes on every render? I would look at that first before considering the API requests as the solution (but perhaps both can end up in the final proposal). |
To solve a rendering performance issue. So what bug are we solving? I think it needs clarifying. |
Thanks for pointing this out. My bad. Just needed a simple blame check to reach here.
From here and here, avatars can change for users not yet saved in Onyx as it depends on the As shown in the test video of the issue, since the avatars keep changing even after the user has stopped keying in, it seems like the side effects of incoming data from API response in a HT environment is resulting in a performance problem. |
Thanks! I'm going OOO soon so @puneetlath can hopefully continue this convo with you @rojiphil. Without doing a deep dive - I would expect that the avatar color would change only if the login itself changes. IMO it feels like the problem here is that we are regenerating an optimistic accountID on each render and inside the
This ticket is unrelated to performance AFAICT... Bug that was reported:
|
Regenerating an optimistic accountID based on searchValue within getOptions() seems to be an intentional change as per this PR here. Not sure if we want to revisit this.
Meanwhile, on having a closer observation of the test video attached to this issue, I noticed a massive lag from 0:34 sec onwards (i.e. after the spinner stops). |
@puneetlath, @mananjadhav Eep! 4 days overdue now. Issues have feelings too... |
Current assignee @mananjadhav is eligible for the Internal assigner, not assigning anyone new. |
@puneetlath, @mananjadhav Huh... This is 4 days overdue. Who can take care of this? |
1 similar comment
@puneetlath, @mananjadhav Huh... This is 4 days overdue. Who can take care of this? |
Sorry for the delay. @mananjadhav what are your thoughts on all this? |
@puneetlath I am not sure if I can get to this sooner, can you please reassign? |
@puneetlath |
interested in reviewing this |
Sounds great, thanks @situchan. Maybe you could start by reviewing the conversation and summarizing where we're at, along with your opinion. |
@puneetlath, @situchan Eep! 4 days overdue now. Issues have feelings too... |
Reviewed all conversations. reviewing proposals. |
Let us know your thoughts @situchan |
@puneetlath, @situchan Whoops! This issue is 2 days overdue. Let's get this updated quick! |
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: 1.3.95.0
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
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Issue found when executing PR #30591
Action Performed:
Pre-requisite: user must be logged in with a HT account.
Expected Result:
The search results should only show the requested account.
Actual Result:
The account being searched is at the top of the list, but then reappears at the bottom constantly changing avatars.
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Bug6261440_1698958778867.Upyl2566_1_.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: