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

Share/editing during sync of moved notes rewrites unrelated notes #11479

Open
Terrance opened this issue Dec 9, 2024 · 3 comments
Open

Share/editing during sync of moved notes rewrites unrelated notes #11479

Terrance opened this issue Dec 9, 2024 · 3 comments
Labels
bug It's a bug high High priority issues mobile All mobile platforms

Comments

@Terrance
Copy link

Terrance commented Dec 9, 2024

Operating system

Android

Joplin version

3.2.2

Desktop version info

Desktop:

Joplin 3.1.20 (prod, win32)

Client ID: 2ca5a676b7954ae89721faa06464e5e6
Sync Version: 3
Profile Version: 47
Keychain Supported: Yes

Revision: 8199362

Backup: 1.4.2
Get Notebook ID: 1.0.1
Joplin Note Attachement rename: 1.2.2
Outline: 1.5.13

Mobile:

Joplin Mobile 3.2.2 (prod, android)

Client ID: d8e98c66054049f0b59e6d8c0db590b2
Sync Version: 3
Profile Version: 47
Keychain Supported: No

Revision: 33942d44c (dev)

Joplin Calendar: 1.2.0
Outline: 1.5.13

Android API level: 33
WebView version: 131.0.6778.41
WebView package: com.google.android.webview
FTS enabled: 1
Hermes enabled: 1

Current behaviour

  1. In another client (using Windows here), move a handful of notes from notebook A to notebook B, and allow to sync
  2. Share text content to the Android client (where notebook A was last used)
    • Sync starts in the background while loading the editor screen
    • Unrelated note titles flash by as the move sync progresses, presumably as the selected note (or position) changes
      • For each title seen, the current editor contents (i.e. what was just shared) is added as a revision of that note

This makes bulk actions rather perilous if you don't ensure other clients are synced up -- I've had to unpick this from revision history of 10+ notes after finding a bulk-move destroyed their contents.

I believe this previously happened against Android 3.1.7 as well as 3.2.2.

Expected behaviour

Background syncs to happen safely and successfully even if the app is launched from a share.

Logs

📎 syncReport-1733701980570.txt

@Terrance Terrance added the bug It's a bug label Dec 9, 2024
@Terrance
Copy link
Author

This might not be limited to shares, but any quick access to the editor -- sharing just conveniently jumps straight into editing the new note.

It also looks like this can happen to a lesser extent on Windows too, having just tried the clients reversed: after moving a handful of notes between notebooks on Android, and creating a new note on Windows, focus is lost from the current note during a sync involving moves, and if you're typing at the time then your changes go into the to-be-moved note (which in this case prevents it from being moved, I guess because a new revision is created stating its parent is the old notebook again).

@Terrance Terrance changed the title Share during sync of moved notes rewrites unrelated notes Share/editing during sync of moved notes rewrites unrelated notes Dec 14, 2024
@personalizedrefrigerator personalizedrefrigerator added mobile All mobile platforms high High priority issues labels Jan 2, 2025
@dejafait
Copy link

FWIW as of 3.2.7 the bug no longer happens in practice to me on Android so far. I guess the new functioning "every 5 minutes" automatic sync does mitigate it quite well: when I switch to a difference device, sync has already happened recently in the background or will be fast as few changes will sync, narrowing the window for the bug to happen.

@Terrance
Copy link
Author

I think on one occasion recently (possibly since 3.2.7) I got a do you want to save changes style prompt appear when editing on Android, which I hadn't seen before? I assume this appeared when the sync happened and tried to send me to a different note.

I've yet to have it come up again when trying to reproduce the original issue manually, nor have I been able to corrupt the note content across notes again, though I may be getting unlucky with timing if the window has effectively recently been reduced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug It's a bug high High priority issues mobile All mobile platforms
Projects
None yet
Development

No branches or pull requests

3 participants