Submission status page should give a clear, detailed error after async validation fails

[jennifer-richards]

Describe the issue

If a submission fails validation in a way that prevents metadata extraction (e.g., due to a title mismatch as in #5691), the submission status page shows a lot of loud warnings about metadata problems. These are irrelevant because the metadata simply weren't populated. Worse, they distract from the event history at the bottom of the page which has the only hint at what specifically went wrong.

This needs to be cleaned up to show only relevant information and, ideally, to more emphatically describe why the draft was rejected.

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[jennifer-richards]

Kind of a special case of #4346

[jennifer-richards]

Another special case that triggered this was a draft containing SVG artwork including the x attribute on the <svg> element. As I understand it, this is not allowed by the RFC SVG schema. The result is this bug being triggered. The backend logs show a more helpful message that should be relayed to the user:

ietf/submit/utils.py(1328) in process_and_validate_submission(): Traceback (most recent call last):
    File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 2183, in validate
        self.v3_rng.assertValid(tree)
    File "src/lxml/etree.pyx", line 3643, in lxml.etree._Validator.assertValid
        lxml.etree.DocumentInvalid: Invalid attribute x for element svg, line 675

and eventually the less specific (but still better than current)

xml2rfc.writers.base.RfcWriterError: [draft path removed]: Error: Invalid document before running preptool.

[jennifer-richards]

Another case seen recently: a submission failed with an error message Error: Expected <rfc> version="3", but found "0". I'm not sure whether this really had a version="0" or if there simply was no version attribute. (That seems more likely.) Regardless, this is another case that should give a useful error instead of simply failing.

[jennifer-richards]

Yet another: a draft came in with <artwork [...] src="art/something.ascii-art"></artwork>. This resulted in no actual error message in the log, just a useless "see above" message. Running it through xml2rfc revealed errors about the src file not existing. From the user's perspective, again, the draft just failed.

[rjsparks]

 <rfc category="std" ipr="trust200902" consensus="true" submissionType="IETF" docName="draft-somebody-did-something-00.txt">

fails because of the .txt in docName, but the result on the UI is inscrutable.

[jennifer-richards]

A file failed submission because ofversion="" in the<rfc...> element. This is accepted without comment by xml2rfc, but causes the following error in the celery logs:

[2023-08-22 07:09:25,002: WARNING/ForkPoolWorker-2]     ietf/submit/utils.py(1328) in process_and_validate_submission(): Traceback (most recent call last):
  File "/workspace/ietf/submit/utils.py", line 1266, in process_and_validate_submission
    render_missing_formats(submission)  # makes HTML and text, unless text was uploaded
  File "/workspace/ietf/submit/utils.py", line 948, in render_missing_formats
    xmltree.tree = prep.prep()
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/preptool.py", line 219, in prep
    tree = self.dispatch(self.selectors)
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 1925, in dispatch
    func(e, e.getparent())
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 2158, in validate_before
    self.die(self.root, 'Expected <rfc> version="3", but found "%s"' % version)
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 1837, in die
    raise RfcWriterError(msg)
xml2rfc.writers.base.RfcWriterError: /a/www/www6s/staging/draft-thomy-json-ntv-00.xml(12): Error: Expected <rfc> version="3", but found "0"

Changing the attribute to version="3" also causes it to fail, this time with

[2023-08-22 07:11:03,164: WARNING/ForkPoolWorker-2]     ietf/submit/utils.py(1328) in process_and_validate_submission(): Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 2121, in validate
    self.v3_rng.assertValid(tree)
  File "src/lxml/etree.pyx", line 3643, in lxml.etree._Validator.assertValid
lxml.etree.DocumentInvalid: Did not expect text in element rfc content, line 12
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/workspace/ietf/submit/utils.py", line 1266, in process_and_validate_submission
    render_missing_formats(submission)  # makes HTML and text, unless text was uploaded
  File "/workspace/ietf/submit/utils.py", line 948, in render_missing_formats
    xmltree.tree = prep.prep()
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/preptool.py", line 219, in prep
    tree = self.dispatch(self.selectors)
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 1925, in dispatch
    func(e, e.getparent())
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 2159, in validate_before
    if not self.validate('before'):
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/preptool.py", line 173, in validate
    return super(PrepToolWriter, self).validate(when='%s running preptool'%when, warn=warn)
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 2153, in validate
    self.die(self.root, 'Invalid document%s.' % (when, ))
  File "/usr/local/lib/python3.9/site-packages/xml2rfc/writers/base.py", line 1837, in die
    raise RfcWriterError(msg)
xml2rfc.writers.base.RfcWriterError: /a/www/www6s/staging/draft-thomy-json-ntv-00.xml(12): Error: Invalid document before running preptool.

Changing the attribute to version="2" fixes the problem (and presumably is the correct value for the structure of the XML).

[jennifer-richards]

As noted on #6221, that PR improves the status page to be less confusing after an error occurred but we should do a better job actually handling the errors we've gathered here before we close this.

[rjsparks]

It would be good to be more transparent about what the failures actually were.

[jennifer-richards]

It would be good to be more transparent about what the failures actually were.

Yes. There's some existing code that grabs exception messages and logs them in the event history. If we can get the actual errors into those event description we'll be almost there. The failures here are hitting generic handling. I'm hoping we can do this in a way that doesn't turn into a lot of special cases...

[jennifer-richards]

#6158 related item that should be reflected clearly on the submission status page.

I've renamed this ticket to be more specific about what it's evolved to track.

[jennifer-richards]

#7107 is another case that should be addressed

[jennifer-richards]

Another case is in #7405 (a <sourcecode> element using the src element instead of using inline content)