[HOLD for payment 2024-12-09] [HOLD for payment 2024-12-07] Search - Read message shown in bold in search router result
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: v9.0.66-0 Reproducible in staging?: Y Reproducible in production?: N If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y Email or phone of affected tester (no customers): [email protected] Issue reported by: Applause Internal Team
Action Performed:
Prerequisite - User A send a message to user B Steps
-
{User B} Navigate to https://staging.new.expensify.com/
-
{User B} Notice a new message is bold in LHN and Search router
-
{User B} Navigate to the message so that the message can be read
-
{User B} Notice LHN is not bold any more
-
{User B} Navigate to Search router
Expected Result:
As the Message is already read the Search router result should not be bold
Actual Result:
Read message shown in bold in search router result
Workaround:
Unknown
Platforms:
- [x] Android: Standalone
- [x] Android: HybridApp
- [x] Android: mWeb Chrome
- [ ] iOS: Standalone
- [ ] iOS: HybridApp
- [ ] iOS: mWeb Safari
- [x] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
https://github.com/user-attachments/assets/da533cae-f814-4ed5-aefa-9a3041cbc367
Issue Owner
Current Issue Owner: @kadiealexander
Triggered auto assignment to @kadiealexander (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
Triggered auto assignment to @aldo-expensify (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.
💬 A slack conversation has been started in #expensify-open-source
:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
- Identify the pull request that introduced this issue and revert it.
- Find someone who can quickly fix the issue.
- Fix the issue yourself.
Besides the chat name (participant name) being bolded, the last message is missing:
and instead we show the email.
This has very likely the same root cause as https://github.com/Expensify/App/issues/53291
⚠️ Looks like this issue was linked to a Deploy Blocker here
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
I think https://github.com/Expensify/App/pull/53293#discussion_r1862818438 fixes this
Made the PR ready for review: https://github.com/Expensify/App/pull/53293
@aldo-expensify this is apparently still not fixed based on qa testing here https://github.com/Expensify/App/pull/53293#issuecomment-2508062917
@aldo-expensify this is apparently still not fixed based on qa testing here https://github.com/Expensify/App/pull/53293#issuecomment-2508062917
😢 , will try to reproduce
Update:
Reproduced in staging again:
btw, I'm still trying to fix my dev env because Auth started crashing.... I reproduced in staging, but I haven't been able to work with my vm yet :(
hmm, I think this is fixed in main, but not in staging. Staging ended up in a not so great state when we CP'd https://github.com/Expensify/App/pull/53293 because we are missing the changes from https://github.com/Expensify/App/pull/53056:
I'm not sure about what to do here... we could also CP: https://github.com/Expensify/App/pull/53056, but I'm not so sure.. it is a big refactor PR, or is that fine? @mountiny do you have some thoughts about this? 😬 🙇
Maybe we can ignore this and deploy https://github.com/Expensify/App/pull/53056 normally on its time since the bold/no bod doesn't sound like a big issue to me
@aldo-expensify Yes I think we can treat this as non-blocker, its minor issue and we can let the refactor go through normal process to catch any regressions on that. Thanks for digging 🙌
The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.68-7 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
- https://github.com/Expensify/App/pull/53293
If no regressions arise, payment will be issued on 2024-12-07. :confetti_ball:
@aldo-expensify @kadiealexander @aldo-expensify The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.69-4 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
- https://github.com/Expensify/App/pull/53293
If no regressions arise, payment will be issued on 2024-12-09. :confetti_ball:
@aldo-expensify @kadiealexander @aldo-expensify The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
No payment due.
Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.