Joplin: Fatal error during startup: Could not find parent at findFolderParent models/Folder.js:151

[jimfarrand]

Environment

Joplin version: 1.0.174
Platform: Linux
OS specifcs: Ubuntu 18.04.3 LTS

Steps To Reproduce

1. Run joplin desktop app

This throws up a dialog box which says:

Fatal error:

Could not find parent

Error: Could not find parent
at findFolderParent (/tmp/.mount_JoplinefHPq4/resources/app/lib/models/Folder.js:151:10

Here's a screenshot

I can't progress past the dialog to get into the app to view my notes.

I have tried deleting my ~/.config/joplin directory and resyncing. This initially seemed to clear the problem, but it re-occurred soon after (maybe the next time I launched Joplin?)

Describe what you expected to happen:

Ideally no error! If that's not possible then, some mechanism to remedy the problem. Eg maybe a dialog saying: "Note such-and-such has become corrupted. Click here to delete it so that you can continue."

Logfile

log-database.txt:

2019-11-15 08:04:30: "Database was open successfully"
2019-11-15 08:04:30: "Checking for database schema update..."
2019-11-15 08:04:30: "Current database version", "24"

log.txt:

2019-11-15 08:04:30: "Profile directory: /home/jim/.config/joplin"
2019-11-15 08:04:30: "Trying to load 1 master keys..."
2019-11-15 08:04:30: "Loaded master keys: 1"
2019-11-15 08:04:30: "ResourceFetcher: Auto-add resources: Mode: always"
2019-11-15 08:04:30: "ResourceFetcher: Auto-added resources: 0"
2019-11-15 08:04:30: "Trying to load 1 master keys..."
2019-11-15 08:04:30: "Loaded master keys: 1"
2019-11-15 08:04:30: "Scheduling sync operation..."
2019-11-15 08:04:30: "Trying to load 1 master keys..."
2019-11-15 08:04:30: "Loaded master keys: 1"
2019-11-15 08:04:30: "Scheduling sync operation..."
2019-11-15 08:04:30: "Trying to load 1 master keys..."
2019-11-15 08:04:30: "Loaded master keys: 1"
2019-11-15 08:04:30: "Scheduling sync operation..."
2019-11-15 08:04:30: "RevisionService::runInBackground: Starting background service with revision collection interval 600000"
2019-11-15 08:04:31: "DecryptionWorker: starting decryption..."
2019-11-15 08:04:31: "DecryptionWorker: completed decryption."
2019-11-15 08:04:34: "RevisionService::maintenance: Starting..."
2019-11-15 08:04:34: "RevisionService::maintenance: Service is enabled"
2019-11-15 08:04:35: "RevisionService::collectRevisions: Created revisions for 0 notes"
2019-11-15 08:04:35: "RevisionService::maintenance: Done in 107ms"

[laurent22]

That would indicate that one of your notebook is referring a parent notebook that doesn't exist. Could you run the following command to see which one it might be?

sqlite3 ~/.config/joplin-desktop/database.sqlite "select id,title,parent_id from folders where parent_id not in (select id from folders) and parent_id != '';"

[jimfarrand]

That query returns 6 matches.

I have another machine which has Joplin running, synced to the same data, and hasn't hit the same problem (I guess because it only triggers at startup). I notice that, I can see folders with the same names as those that are returned by your query above - but they have different IDs.

Based on your query I cooked up this one, to see if there are any notes attached to the orphaned folders:

sqlite3 ~/.config/joplin-desktop/database.sqlite "select id,title from notes where parent_id in (select id from folders where parent_id not in (select id from folders) and parent_id != '');"

And indeed there are. Again, they appear to be duplicates of notes that I can see in the running Joplin - same names but different IDs.

Interestingly, the notes and folders that are now causing the problem previously disappeared from Joplin. I thought at the time that I had inadvertently deleted them somehow, but now I'm not so sure. Fortunately, shortly before the notes disappeared, I'd been experimenting with the "export to markdown" feature, so I just imported the notes back in.

I guess that the problematic folders returned by your query are the ones that previously mysteriously vanished, and the duplicates are the ones that I later imported back in.

Here's what I'm considering doing:

1) Exporting everything so I know all my notes are safe.
2) Turning the two queries above into DROPs, to remove first the notes attached to orphaned foldered and then the orphaned folders.

Regarding (1). If I export to JEX format, is it going to export the orphans as well? Obviously I don't want to find after restoring the export that the problem still exists (or worse - the orphans cause the import to fail).

Regarding (2). Is this safe/sane? Is there anything other than the notes and folders tables that need to be cleaned up? Or is it better just to export everything, nuke the content on my webdav server and start over from a fresh import?

[jimfarrand]

I wonder if it might be possible to change the code so that, orphaned folders are automatically re-parented to the top level? That if this issue hits anyone else they will have a slightly nicer time.

[laurent22]

I wonder if it might be possible to change the code so that, orphaned folders are automatically re-parented to the top level? That if this issue hits anyone else they will have a slightly nicer time.

Yes, the app in general is designed to fail hard when there's a bug or exception so that it can be improved, but now that we know that non-existing parents can happen (though not sure how), I'll change the code to handle this. Probably indeed by displaying these folders at the top level.

[laurent22]

For now, if you don't need these problematic folders (those returned by my first sql query), you can get the ID and delete them on the sync target. Then clear your local data (delete the profile dir) and re-sync. Modifying the SQL data directly is not recommanded as you might end up with invalid data, which might be very hard to make sense of or fix.

[jimfarrand]

Thanks for your help! Do I need to do anything about the notes that will be orphaned when I delete the orphaned folders? I assume I can delete them in the same way (but it's a reasonable amount of work so I won't if it's not strictly necessary :) )

[laurent22]

If I remember correctly, unparented notes don't cause any problem, but they also don't appear anywhere (except maybe in search results).

[tessus]

@laurent22 it's very strange that it is possible for a note to lose the association to a folder. I remember that something like this was possible by dragging a note to the root "folder" (which is not a folder, but the collapsible section name) called Notebooks. But you prevented that with a fix back then.
However, it is even stranger that a folder references a parent that does not exist. This shouldn't even be possible, if the foreign key relations and constraints in the database are set up correctly.
You mentioned to change the code to show the folders at the top level. I don't think this is a good idea. Unless we know why these folders "disappeared", we should create a special folder called "GHOST" or "Ghost" and put them there.

[laurent22]

A good part of the database is really like a cache of the sync target data, so there's no foreign keys or other constraints. It would be impossible to get anything working with local constraints. Or if such constraints exited they should be on the sync target but of course it's just plain files so we can't have this.

I don't know why the parent folder is gone (it existed at some point since the UUID doesn't come out of nowhere), but normally it shouldn't happen.