How to standardize output of errors and warnings

[espenfl]

At some point we will start to handle errors and warnings from our codes. Where should we put those? I see some options:

• put it in some kind of container: mycalculation/myworkchain.outputs.misc.notifications.errors/warnings etc.
• put it in as a dedicated node: mycalculation/myworkchain.outputs.notifications.errors/warnings etc.

As we are progressing with the implementation of this in aiida-vasp now, we would like to try to coordinate this across the board in order to not break future backwards compatibility.

Formally, the second suggestion seems to be the right one, but we also create an additional node. However, I suspect it would be nice to know where to look for the notifications in each plugin and that this is standardized. Not all plugins will have containers like misc etc. Combining this issue with https://github.com/aiidateam/aiida-core/issues/4311 would also standardize how the entries in notifications behave.

What do you think?

[espenfl]

We continue from https://github.com/aiida-vasp/aiida-vasp/pull/374.

I fancy the separate node as: easier to coordinate across plugins

I don't really see how this makes it easier to coordinate compared to a feature that already exists in aiida-core?

Not sure what is meant here. Which feature is already existing in aiida-core?

Plan in the long run is that we get some kind of standardized objects for the notifications with the purpose of using them in workchains etc. to facilitate e.g. error corrections.

So what would they actually look like? Can you give an example of the structure of the notifications data structure, whether it be its own node or a key in the misc node? What do the warnings and errors key contain?

One example, just a suggestion that was made in the parser for aiida-vasp: https://github.com/aiida-vasp/parsevasp/blob/develop/parsevasp/stream.yml

Of course the regex is not that important to store for later. This is the config for how we detect a specific error for the parser. But some of the other entries would be useful to store. Then there is all kinds of auxiliary functionality like __str__, number of entries, etc. so that we can dump this easily to a log if need be and/or reach it in some way. The errors and warnings would of course also contain a history, in case you would need the sequence to be able to arrive at some kind of correction. It would also make sense to separate errors, warnings, info etc.