Joplin keeps showing "Syncing"

Support
1

Operating system

macOS

Joplin version

3.0.15

Desktop version info

Joplin 3.0.15 (prod, darwin)

Client ID: 58f713f3db09496389ddc04056cf9930
Sync Version: 3
Profile Version: 47
Keychain Supported: Yes

Revision: 598677b

Backup: 1.4.2
Joplin Batch: 0.2.2
Joplin Publisher: 1.1.4

Sync target

OneDrive

Editor

Markdown Editor

What issue do you have?

In the case of a long startup, Joplin gets stuck in a synchronization deadlock. I suspect it's because I'm continuously calling the GET /folders? interface, but I'm not sure why there is a problem with this interface.

Screenshots

Snipaste_2024-10-06_12-41-28.png
Snipaste_2024-10-06_12-41-28.png1230×1670 469 KB

image
image1228×2036 253 KB

Log file

last_1000_lines.txt (62.6 KB)

2

When I have problems like these I just delete the locks from the cloud drive (ensuring nothing is syncing at a time).

3

I can quit and reopen Joplin, which can temporarily solve this problem. But it's just annoying.

4

This problem has occurred again.

image
image1228×1070 167 KB

5

I compiled instructions for how to get a stack trace for the "Synchronization is already in progress" message. However, I no longer think that a stack trace for this message will be useful — it seems to be coming from the regularly scheduled sync. I'm posting them here anyway because they might still be helpful for related debugging:

Debugging: Getting a stack trace

To get stack trace information for the "Synchronization is already in progress" error:

  1. Open the "Sources" tab in Joplin's developer tools.
  2. Press ctrl-p (I think cmd-p on MacOS).
  3. Type Synchronizer.js and press enter.
  4. Press cmd-f and search for Synchronisation is already in progress
  5. Add a breakpoint to the line by clicking on the line number.
  6. Wait for the breakpoint to be triggered.
  7. Scroll to and inspect the "Call stack" section in the right sidebar.
  8. Check the "Show ignore-listed frames" checkbox.
Screen recording demonstration

Note that it might be necessary to check "Show ignore-listed frames".

More useful might be determining where the synchronizer is getting stuck. Temporarily enabling debug logging might also help with this.

6

Thank you, I have recorded the Devtools Debugger video, and the logs have been enabled. If this issue occurs again, I will add it below.

1 Like
7

Thank you for the information! Based on the stack trace, the error message seems to be coming from the regularly scheduled sync:

Unfortunately, this doesn't show where the ongoing sync is getting stuck. One possibility is fetchWithRetry in shim.ts), which retries a request after an increasing delay. However, for retryable requests, fetchWithRetry should fail after fetchMaxRetry_ = 5 failed requests (45000 ms + time for fetch to complete or fail).

8

The problem has occurred again, but I have enabled the debug log according to the instructions above.

image
image1770×858 200 KB

last_2000_lines.txt (128.8 KB)

1 Like
9

Thank you! I'm highlighting the last error before the repeated Synchronisation is already in progress. State: in_progresss:

Code: ENOTFOUND
FetchError: request to https://graph.microsoft.com/v1.0/drive/root:/%E5%BA%94%E7%94%A8/Joplin/locks/1_1_58f713f3db09496389ddc04056cf9930.json failed, reason: getaddrinfo ENOTFOUND graph.microsoft.com
    at ClientRequest.<anonymous> (/Applications/Joplin.app/Contents/Resources/app.asar/node_modules/@joplin/lib/node_modules/node-fetch/lib/index.js:1491:11)
    at ClientRequest.emit (node:events:514:28)
    at TLSSocket.socketErrorListener (node:_http_client:495:9)
    at TLSSocket.emit (node:events:514:28)
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)

One possible explanation: Joplin might not be setting Synchronizer.state_ back to idle. In particular, the call to releaseLock isn't wrapped in one of the try/catch blocks in Synchronizer.start_. As such, if an error occurs in releaseLock, Synchronizer.start might exit before setting state_ back to idle.

2 Likes
10

Okay, do I need to provide any other information? If necessary, I can also run the Joplin development environment locally, although I am not familiar with the internal code of the Joplin project

11

If the issue was caused by the releaseLock issue mentioned above, it should be fixed by this pull request. Until a fix is merged/included in a release, be aware that disabling sync locks (available in the 3.1.x pre-releases) may also resolve the issue.

I don't think any other information is necessary.

1 Like
12

Thank you, the issue has been confirmed to be fixed after updating to the latest version.