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.
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:
Open the "Sources" tab in Joplin's developer tools.
Press ctrl-p (I think cmd-p on MacOS).
Type Synchronizer.js and press enter.
Press cmd-f and search for Synchronisation is already in progress
Add a breakpoint to the line by clicking on the line number.
Wait for the breakpoint to be triggered.
Scroll to and inspect the "Call stack" section in the right sidebar.
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.
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).
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)
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
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.
Sync locks were removed, but only in v3.2.x. In v3.1.x, they need to be disabled using a feature flag (settings > synchronization > advanced > "enable sync locks").
At least 1-2 users have reported that OneDrive sync is creating additional folders in /Apps named Graph (or Graph 2 or similar). If the sync folder changes from /Apps/Joplin -> /Apps/Graph, this might cause sync issues:
