I am opening this thread as I expect some user attention on the github issue and don’t want discussion there, that isn’t directly relevant for users and might cause confusion:
Up to now we have three cases of people with file entries in their db which do not belong to any folder. That’s not directly related to the db migration, but given we iterate over everything instead of folder prefixes they came up now. I see two options to handle this:
Tell them to reset db.
Advantage: If whatever caused those erroneous file entries had other bad effects on the db, those are gone.
Disadvantage: DB reset - annoying and potential for conflicts.
Adjust the transition to just ignore those file entries and release 1.4.1 immediately.
Advantage: No db reset, minimal code change needed. People not yet upgraded to 1.4.0 don’t get any problems (though more than half the users have already upgraded).
Disadvantage: Still need manual intervention to upgrade when on 1.4.0, as https://github.com/syncthing/syncthing/pull/6385 isn’t in 1.4.0.
Release an 1.4.1 RC fast after merging https://github.com/syncthing/syncthing/pull/6367 - that unintentionally already fixed this failure mode (as it works on folder prefixes). Has about the same (dis)advantages as 2., but feels more normal (as RC).
Agreed. I was worried we’d get a huge stream of affected users - luckily that doesn’t seem to be the case.
Related: What do you think about using sentry directly in Syncthing or add new report types in the monitor next to panics to report unclean exits like this (could also include the case where services don’t stop in time etc)? We could both better judge how many users are affected and it might have caught it in RC already.
According to https://data.syncthing.net ~47% are on v1.4.0, which correlates to users who have set update=automatic. Keep in mind that many people are working from home right now so it might take some time for the rest to update manually.