I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

I closed this issue now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

@kodebach wrote in #3529: In this case [failing] is the correct option. If the file contains invalid key names, you either edited the file manually (in which case you can do that again to fix the problem) or the plugin is completely broken and actually produced the invalid key name (in which case there is no chance of fixing the key name anyway).

It could be also a corruption of some other kind, e.g. some script did a wrong change or even a hard disc failure. I wouldn't go for more than a warning, as not starting the application for a maybe irrelevant option can be a very severe problem.

Applications can always decide to exit on warnings (and normal applications probably should do that) but in some situations there might be no way to let applications start with a present error, e.g. if the error is already within kdbOpen, applications would not not even get the KDB handle.

But the question is, what would the ni plugin return, if it encouters an invalid key name? In any case, at least this one key will be lost.

To me a warning is something that "should ideally be fixed", but "can also be safely ignored". So IMO ignoring a warning should never lead to data loss.

That is actually, why we need a mode were errors are ignored. Then we can properly return errors, when something really bad happend.

Yes, this would basically mean we need critical and non-critical errors.

Or: we treat such things as corruption of the database and build some other tools (post 1.0) to fix such corruptions. Something like fsck? These tools obviously would not be able to use the API but they could use the plugin if the plugin would continue processing the configuration file even in the case of errors.

Or: we make it internally as warning, and the spec plugin turns it to an error if the warning is related to a specified key. If the name is invalid, it is not such a case anyway. This could be very problematic if the erroneous key is actually a typo from a name of a specified key. And this approach is probably also a too big burden for the spec plugin.

Anyway: We definitely need a consistent error concept. See also #2726.