Skip to content

[HOLD for payment 2021-09-28] If you mark a message as unread and close the app or minimize it, the unread status is removed. #4855

Closed

Description

@kavimuru

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:

  1. Open app and login
  2. Open any chat
  3. Long tap any old message
  4. Tap "Mark as Unread"
  5. Force close the app and open it again
  6. Open the same chat as before

Expected Result:

Message is still marked as unread

Actual Result:

Message will lose unread status after force close + reopening

Workaround:

Unknown

Platform:

Where is this issue occurring?

  • Web
  • iOS ✔️
  • Android ✔️
  • Desktop App
  • Mobile Web

Version Number:
1.0.88
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Bug5210356_unread-issue.mp4

Expensify/Expensify Issue URL:

View all open jobs on GitHub

Upwork job link https://www.upwork.com/jobs/~0160911a1308566e83

Activity

  1. OSBotify commented on Aug 26, 2021

    @OSBotify
    Contributor

    👋 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:

    1. Identify the pull request that introduced this issue and revert it.
    2. Find someone who can quickly fix the issue.
    3. Fix the issue yourself.
  2. MelvinBot commented on Aug 26, 2021

    @MelvinBot
    Contributor

    Triggered auto assignment to @Jag96 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

  3. isagoico commented on Aug 26, 2021

    @isagoico

    Confirmed this is also happening in Prod, removing the deploy blocker label.

  4. added and removed
    DeployBlockerCashThis issue or pull request should block deployment
    on Aug 26, 2021
  5. removed their assignment
    on Aug 26, 2021
  6. added
    ExternalAdded to denote the issue can be worked on by a contributor
    on Aug 26, 2021
  7. MelvinBot commented on Aug 26, 2021

    @MelvinBot
    Contributor

    Triggered auto assignment to @michaelhaxhiu (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

  8. meetmangukiya commented on Aug 27, 2021

    @meetmangukiya
    Contributor

    This is not just for force close, this occurs for all activeReports. Whenever, the app visibility changes, the activeReport gets marked as read.

    https://reactnative.dev/docs/appstate
    Our isVisible implementation for mobile always returns true

    // Mobile apps do not require this check for visibility as
    // they do not use the Notification lib.
    /**
    * @return {Boolean}
    */
    const isVisible = () => true;

    which leads to always marking the report as read irrespective of visibility changing to active or background

    /**
    * Records the max action on app visibility change event.
    */
    onVisibilityChange() {
    if (Visibility.isVisible()) {
    updateLastReadActionID(this.props.reportID);
    }
    }

    So, when we mark something as unread and change the app or try to close it, AppState's change event gets triggered, our handler gets triggered, since isVisible is always true, we end up marking the report as read, and hence, we don't get the marker again.

    Proposal

    Use AppState to get currentState and only return true when the app is active.

    function isVisible() {
        return AppState.currentState === 'active';
    }

    and change onVisibilityChange method to check if app is active and drawer is not open

    onVisibilityChange() {
        if (Visibility.isVisible() && !this.props.isDrawerOpen) {
            updateLastReadActionID(this.props.reportID);
        }
    }
  9. 34 remaining items

  10. isagoico commented on Sep 13, 2021

    @isagoico

    Issue reproducible during KI retests.

  11. michaelhaxhiu commented on Sep 15, 2021

    @michaelhaxhiu
    Contributor

    Issue is still in progress, PR is seeing steady progress. Let's keep it up.

  12. Jag96 commented on Sep 15, 2021

    @Jag96
    Contributor

    PR merged!

  13. botify commented on Sep 15, 2021

    @botify

    ✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

  14. isagoico commented on Sep 20, 2021

    @isagoico

    Issue reproducible during KI retests.

  15. added
    Awaiting PaymentAuto-added when associated PR is deployed to production
    and removed on Sep 21, 2021
  16. changed the title [-]If you mark a message as unread and close the app or minimize it, the unread status is removed.[/-] [+][HOLD for payment 2021-09-28] If you mark a message as unread and close the app or minimize it, the unread status is removed.[/+] on Sep 21, 2021
  17. botify commented on Sep 21, 2021

    @botify

    The solution for this issue has been 🚀 deployed to production 🚀 in version 1.1.0-2 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

    If no regressions arise, payment will be issued on 2021-09-28. 🎊

  18. isagoico commented on Sep 27, 2021

    @isagoico

    Issue not reproducible during KI retests. (Fixed)

  19. isagoico commented on Oct 4, 2021

    @isagoico

    Issue not reproducible during KI retests. (Fixed)

  20. Jag96 commented on Oct 4, 2021

    @Jag96
    Contributor

    Paid!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Awaiting PaymentAuto-added when associated PR is deployed to productionEngineeringExternalAdded to denote the issue can be worked on by a contributorReviewingHas a PR in reviewWeeklyKSv2

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions