Skip to content
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

check if reports data is up to date before update last read action id #6095

Merged

Conversation

jolivervidal
Copy link
Contributor

Details

Verification added for updating the list of unread messages only if the reports data is up to date

Fixed Issues

$ #5405

Tests

  1. Open a chat in the browser with the purpose to create cached data
  2. Close the tab
  3. Open the same chat on an other device
  4. Send a message to this chat
  5. Open the same chat again on the browser used at the point 1
  6. Verify that the message sent by ourself in the other device does not appear as unread
  7. Repeat the same steps with the other devices

QA Steps

The same steps as above

Tested On

  • Web
  • Mobile Web
  • Desktop
  • iOS
  • Android

Screenshots

Web

web

Mobile Web

mobile web

Desktop

desktop

iOS

ios

Android

android

@jolivervidal jolivervidal requested a review from a team as a code owner October 28, 2021 11:13
@MelvinBot MelvinBot requested review from johnmlee101 and removed request for a team October 28, 2021 11:13
@github-actions
Copy link
Contributor

github-actions bot commented Oct 28, 2021

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

@jolivervidal
Copy link
Contributor Author

I have read the CLA Document and I hereby sign the CLA

Copy link
Contributor

@johnmlee101 johnmlee101 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few minor changes, I'm going to add another reviewer into the mix as well

src/libs/actions/Report.js Outdated Show resolved Hide resolved
src/libs/actions/Report.js Outdated Show resolved Hide resolved
src/libs/actions/Report.js Outdated Show resolved Hide resolved
@johnmlee101
Copy link
Contributor

@parasharrajat (it says your busy so lmk if you'd rather ignore) or @Beamanator did you want to do a secondary review?

@jolivervidal
Copy link
Contributor Author

Updated. And waiting for secondary review by one of the other engineers

@parasharrajat
Copy link
Member

@johnmlee101 Thanks for tagging in. Yup, I was busy but now I am available so reviewing it.

src/libs/actions/Report.js Outdated Show resolved Hide resolved
src/pages/home/report/ReportActionsView.js Outdated Show resolved Hide resolved
parasharrajat
parasharrajat previously approved these changes Nov 3, 2021
Copy link
Member

@parasharrajat parasharrajat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks good. I have not tested it with the reproduction steps but I presume that it is working.

Just tested it on the Web with the exact reproduction steps and it is working well.

# Conflicts:
#	src/libs/actions/Report.js
#	src/pages/home/report/ReportActionsView.js
# Conflicts:
#	src/libs/actions/Report.js
Copy link
Contributor

@kidroca kidroca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy that this solution works, but I think we can make it better if we prevent updates during consecutive loads as well

The vast majority of the time the bug would happen during startup, but there's always a chance that on a consecutive fetch something that we don't have locally might come

One of the potential cases is when we suspend the app for a long time then resume the app - see onVisibilityChange. When we focus the app there's a call that would again fetch reports, but we might false set a last read if the call hasn't completed yet.
While the app is suspended we can't guarantee it has received all updates I guess that's why we're re-fetching reports on focus

I think we should go with something like: if reports are loading don't update the last read message

  • in case something new comes - we have new messages
  • if nothing new comes - we haven't falsely marked it as unread

So instead of preventing setting last read only during initial report loading, we can prevent it if it happens during report loading in general

Comment on lines 1424 to 1426
function isReportDataUptoDate() {
return isReportDataFresh;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not really telling us whether report data is up to date, but whether initial report fetching is over.
The return value will stay true ever since

Without a server check we can't reliably know whether we're up to date, we can only guess that we're not
To know whether we're synced we should at least check

  • we're online
  • we're connected to pusher
  • we have no pending request regarding reports (or anything)

Then, yes we're probably up to date


IMO the variable should be renamed to isReportDataLoading or isReportDataLoaded and should be updated at the start of the load and at then end, similarly to how fetchActionsWithLoadingState works

If that's the case we might also put in in ONYXKEYS e.g. isReportDataLoading and then subscribe the ReportActionsView to that key

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. It's a better solution to use a more generic approach like this. I added a new ONYX KEY called IS_LOADING_REPORT_DATA. I chose that name to keep it the same way the existing loading keys.
This key is set in the fetchAllReports function and it updates the variable called ´isReportDataLoading´ in the Report.js. It is not necessary to subscribe the view to that key, because I moved the if statement inside the updateLastReadID like you suggested

Comment on lines 132 to 136
if (!this.props.isDrawerOpen) {
Report.updateLastReadActionID(this.props.reportID);
if (Report.isReportDataUptoDate()) {
Report.updateLastReadActionID(this.props.reportID);
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better to move this check inside updateLastReadActionID
There are other places that could call updateLastReadActionID while data is still being fetch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@jolivervidal
Copy link
Contributor Author

Updated regarding @kidroca suggestions.

@mallenexpensify
Copy link
Contributor

Dropping this link in here so we'll hopefully get a ping when this closes, we're holding on it #3981

@jolivervidal
Copy link
Contributor Author

Waiting for @johnmlee101 review

@johnmlee101
Copy link
Contributor

Was busy last week, looking now!

Copy link
Contributor

@johnmlee101 johnmlee101 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! @kidroca did you want a final pass of review?

Copy link
Contributor

@kidroca kidroca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @johnmlee101 LGTM!

@johnmlee101 johnmlee101 merged commit e60aa8c into Expensify:main Nov 17, 2021
@OSBotify
Copy link
Contributor

@jolivervidal, Great job getting your first Expensify/App pull request over the finish line! 🎉

I know there's a lot of information in our contributing guidelines, so here are some points to take note of 📝:

  1. Now that your first PR has been merged, you can be hired for another issue. Once you've completed a few issues, you may be eligible to work on more than one job at a time.
  2. Once your PR is deployed to our staging servers, it will undergo quality assurance (QA) testing. If we find that it doesn't work as expected or causes a regression, you'll be responsible for fixing it. Typically, we would revert this PR and give you another chance to create a similar PR without causing a regression.
  3. Once your PR is deployed to production, we start a 7-day timer ⏰. After it has been on production for 7 days without causing any regressions, then we pay out the Upwork job. 💰

So it might take a while before you're paid for your work, but we typically post multiple new jobs every day, so there's plenty of opportunity. I hope you've had a positive experience contributing to this repo! 😊

@OSBotify
Copy link
Contributor

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

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by @johnmlee101 in version: 1.1.15-18 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@OSBotify
Copy link
Contributor

🚀 Deployed to production by @roryabraham in version: 1.1.16-10 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants