Fwiw one common denominator in the files throwing the error is that titles with a stray double quote " seem to be the culprit, in other words an odd number of "s even if the title itself is properly contained in an opening and closing " pair.
Could this be the issue, and is it possible to relax parsing?
This may sound a little ridiculous but the these are old confidential client notes, so I don't really want to put this up.
But as i said the consistent theme with the notes that failed to import is the title front matter has an unmatched ending double quote, which presumably leaves a text string hanging without a tag in the front matter conversion.
Seems to me very likely that is the issue, easily replicated with any random string, but the question is could the import logic be tweaked to address that gracefully.
update: Ok, it is definitely the unpaired double quote throwing the error.
However, the file actually seems to be imported, but the error crashes the wider import routine which then exits (causing extensive processing on sync and subsequent deletion/trash emptying to retry the process.
I don't expect we could (or should) import an invalid FrontMatter header. Importing invalid data can have side effects, including subtle data loss that may not be noticed until it's too late.
What app exported these files? Because that's what should be fixed. Otherwise the only solution would probably be a bespoke script that fixes the files for you before your import them. ChatGPT would do that easily for you in Python or your language of choice
Right, but the note itself is in fact imported but without any front matter. And only after import does it throw the error and then exit the import. I suggest the behaviour should be either
a) throws the error and discards the note or
b) discards the front matter and continues the import
