-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
DeleteComment conflict resolver #50919
Conversation
@shubham1206agra Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
cc4fb33
to
b26e6cd
Compare
@shubham1206agra let us know what is your eta for this review? thanks! |
@shubham1206agra any news? |
# Conflicts: # src/libs/actions/Report.ts # src/libs/actions/RequestConflictUtils.ts # tests/actions/ReportTest.ts # tests/unit/RequestConflictUtilsTest.ts
I think Shubham is going to be busy with some other projects now so in sake of focus I will try to reassign |
I found a small problem. Until we process the response, we do not remove the request from PersistentRequests. So, if a request is made, but before the response is received, the client can go offline. So, the request is not removed from PersistentRequests. So,
Here is a video with 8kbps download speed deleteRequestLost.mp4I think we should consider not removing a DeleteXXX request if a corresponding Add/Update requests were already tried by the client. |
@mountiny @c3024 this is a bug that is happening on main too, I just checked and it sends duplicated My code is preventing the duplicated request to be sent, so It can't delete the original because as stated the Seems something really weird, seems that the ReportActionCompose is adding back the last text, and submitting it. |
I don't think calling When a client makes a write request, unless it receives a response it cannot know that the request is successful. In this case, the first App/src/libs/Network/SequentialQueue.ts Line 99 in f251dbc
When the client fails to stay online till the response returns, this ongoing request, AddComment here, is added back to PersistedRequests. App/src/libs/Network/SequentialQueue.ts Line 111 in f251dbc
If client sends the AddComment again, I think backend has some way to understand that this is a duplicate request that was already processed. It must not be doing anything. Also, when we go online, ReconnectApp sends back the latest update which in this case includes the first successful AddComment also, so the message appears again on the screen. So, I think if we can know that client tried an AddXXX request somehow, we should not remove the DeleteXXX request corresponding to the AddXXX action in this case because AddXXX might have been successful on the backend. So, we should not delete the DeleteXXX request and should send this request to backend. |
Ok, will take a look at that case |
ok, I will add inside of RequestConflictResolver type a |
# Conflicts: # src/libs/actions/Report.ts # src/libs/actions/RequestConflictUtils.ts # tests/actions/ReportTest.ts # tests/unit/RequestConflictUtilsTest.ts
@c3024 PR updated |
Offline behaviour with "Force offline" is different for Threads Test. forceOffline.mp4This should not be a problem for production because that option does not exist in production but QA will see a different result here for the test on staging. |
@gedu, can you please check the above comment? I wonder why "Force offline" is behaving differently from setting offline in Dev Tools or disconnecting network on device settings level. |
@c3024 yes, taking a look now |
@c3024 Fix it and added a test to cover that case |
This issue still remains on iOS Safari. deleteThreadOnMain.mp4deleteThreadOnThisBranch.mp4 |
Seems that |
Updated @c3024 can you review it? |
@@ -96,15 +96,15 @@ function process(): Promise<void> { | |||
pause(); | |||
} | |||
|
|||
PersistedRequests.remove(requestToProcess); | |||
PersistedRequests.endRequestAndRemoveFromQueue(requestToProcess); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason for changing this? I see that remove
function has no changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it was doing more than just remove
, I need to provide more clarity on what it was actually doing to avoid any misuse.
Reviewer Checklist
Screenshots/VideosAndroid: NativeaddAndroid.mp4Android: mWeb ChromeaddAndroidmWeb-compressed.mp4iOS: NativeaddiOS.mp4iOS: mWeb SafariaddiOSmWeb1.mp4addiOSmWeb2.mp4addiOSmWeb3.mp4MacOS: Chrome / SafariaddChrome.mp4MacOS: DesktopaddDesktop.mp4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Details
Any request with command AddXXX that I find, I will try to not perform a request, given that the backend doesn't have information about it.
If there is no AddXXX or it is already processing, I will delete any actions between that processing/existing comment and the DeleteComment. The server just need to delete it and not perform any kind of update like (UpdateComment, AddEmojiReaction, etc)
There is a special case, when the comment will be use to create a thread (an OpenReport is executed) in that case, the safer solution is to send all the requests as planned instead of deleting, given that DeleteComment is by reportActionsID and the logic could be complicated when multiple random actions happens in a thread.
Fixed Issues
$ #50074
PROPOSAL: -
Tests
DeleteComment request:
Send a message (wait for this message to success)
Go to Offline
Edit the message
Add emoji reaction
Remove emoji reaction
Delete the message
Go to online
Just the DeleteComment request should be send
Verify that no errors appear in the JS console
Offline tests
No requests:
Threads
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label and/or tagged@Expensify/design
so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
deleteComment_chrome.mp4
MacOS: Desktop