Open bram-atmire opened 1 month ago
The cited error response is mostly the error message that the registrar's service got from some schema-driven XML parser. We shouldn't depend on knowing or guessing what parser they use today, so it is risky to do more than to display the document we sent together with their response.
We could acquire a copy of the schema that we intend to follow in our crosswalk, and parse the crosswalk output with it to check validity before sending. That might give us a chance to display better information about any syntactic problems.
Second thought: rather than generating a schema-driven parser just to check for problems, simply log the metadata document as part of the error message and let people use their preferred tools to examine it.
Describe the bug
When the DOI Organizer errors out, a typical error signature looks like:
There are two problems with this:
If the DOI is not yet on a live item, it is not super easy to identify the offending item from doi:10.13025/14703, as it requires a lookup/inspection into the DOI table. Would be great if the item uuid would be logged alongside the error.
The error message doesn't make it clear what's wrong with the metadata of the item. Cases that we have seen that is causing errors are null/empty metadata values for a specific field, or the DOI being present twice, but there are other cases as well.
Would be really great if the error statement makes it clear which metadata field or value is causing the problem.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The offending item and offending metadata field should be clear from the log, so that the errors are easily resolved.