Mobile: Fixes #11317: Fix race condition which may cause data loss, particularly before or after pasting text in the note editor #11334
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There have been various issues raised regarding the latest input text intermittently being lost on a note on the mobile app. I have managed to find a way to consistently recreate this issue.
By adding additional logging at various places and then reproducing the issue, I was able to figure out the root cause of the issue. The issue is caused by a race condition in saveNoteButton_press.
If the execution of the method overlaps, when "BaseModel.diffObjectsFields(comp.state.lastSavedNote, note)" is executed, it will incorrectly think that the note has not changed, when the value of comp.state.note has changed between entering the method and setting the stateNote field. Therefore the subsequent logic to save the note to the database will not save changes updated after saving the note, but before setting stateNote.
The fix for this is to simply set the lastSavedNote value (used for comparing the previous note state) to use the 'savedNote' value, rather than the 'note' value which may have newer changes than 'savedNote'. See #11317 for a video of the issue being reproduced.
EDIT: an additional change was required to ensure that if the note was exited quickly after making the last change, no input data would be lost. The updated video demonstrates no input being lost after a rapid exit of the note after making changes.
Attached are videos of the behaviour following the code change.
Exit note slowly, showing latest input renders correctly in view mode when exiting edit mode:
https://github.com/user-attachments/assets/e2af19b2-3296-40f1-9ad9-7b8f2b9c4cff
Exit note quickly, without waiting for note to re-render:
https://github.com/user-attachments/assets/b0df0a13-7811-463e-9ad1-97ceab8b8202
PLEASE NOTE: The CodeMirror error which pops up at the start of the video is pre-existing, and happens sometimes when opening very large notes in edit mode. But the error popup is not visible when running the published app (but the error can still be found in the logs) rather than a dev build