BUG: Secondary document too long + service email generated when efiling fails

[JessicaMarine]

Describe the Bug The IRS is getting the "Uh oh" error when trying to eFile a document in 6944-11. The eFiling was not successful, but a service email was generated. This is probably an order of operations issue.

[Note: Looking into why the PDF couldn't be uploaded -- determined failure was caused by title being too long]

Business Impact/Reason for Severity

In which environment did you see this bug? Prod

Who were you logged in as? Reported by IRS

What were you doing when you discovered this bug? (Using the application, demoing, smoke tests, testing other functionality, etc.) IRS trying to file a document

To Reproduce Steps to reproduce the behavior:

1. Log in as an IRS user
2. Go to 6944-11
3. Try to eFile a Motion for Leave to File Reply to Response to Order that resp. motion is granted, and petr. by 4/12/21, shall show cause why facts and evidence set forth in resp. proposed eighth stipulation of facts, marked exhibit A, and ninth Stipulation of facts, marked exhibit B, should not be deemed accepted as established for the purpose of this case. Exhibits A and B to resp. motion for order to show cause why proposed facts and evidence should not be accepted as established pursuant to rule 91(f) are hereby sealed until further direction of the Court. The duplicate filing of resp. motion for order to show cause why proposed facts and evidence should not be accepted as established pursuant to Rule 91(f) at index number 735 is stricken from the record.
4. Secondary (lodged) Document is: Reply to Response to Order that resp. motion is granted, and petr. by 4/12/21, shall show cause why facts and evidence set forth in resp. proposed eighth stipulation of facts, marked exhibit A, and ninth Stipulation of facts, marked exhibit B, should not be deemed accepted as established for the purpose of this case. Exhibits A and B to resp. motion for order to show cause why proposed facts and evidence should not be accepted as established pursuant to rule 91(f) are hereby sealed until further direction of the Court. The duplicate filing of resp. motion for order to show cause why proposed facts and evidence should not be accepted as established pursuant to Rule 91(f) at index number 735 is stricken from the record.
5. Select "No Objections"
6. Try to submit -- get Uh Oh error
7. Note that a service email is sent even though the eFiling failed.

Expected Behavior

• User is notified that the document title is too long in the UI
• Service email is not sent unless the eFiling was successful

Actual Behavior

• User is not being notified what the issue is -- getting the "Uh oh" error is unhelpful
• Service email is being sent before the eFiling is successful

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Cause of Bug, If Known

• Observed this error message in the logs. It appears that somehow they are exceeding the limit of the title of the secondary document:

The Case entity was invalid. {"documentTitle":"'docketEntries[750].secondaryDocument.documentTitle' length must be less than or equal to 500 characters long"}

Process for Logging a Bug:

• Complete the above information
• Add a severity tag (Critical, High Severity, Medium Severity or Low Severity). See below for priority definition.

Severity Definition:

• Critical Defect Blocks entire system's or module’s functionality No workarounds available Testing cannot proceed further without bug being fixed.

• High-severity Defect Affects key functionality of an application There's a workaround, but not obvious or easy App behaves in a way that is strongly different from the one stated in the requirements

• Medium-severity Defect A minor function does not behave in a way stated in the requirements. Workaround is available and easy

• Low-severity Defect Mostly related to an application’s UI Doesn't need a workaround, because it doesn't impact functionality

Definition of Done (Updated 4-14-21)

Product Owner

• [x] Bug fix has been validated in the Court's test environment

Engineering

• [x] Automated test scripts have been written
• [x] Field level and page level validation errors (front-end and server-side) integrated and functioning
• [x] Verify that language for docket record for internal users and external users is identical
• [x] New screens have been added to pa11y scripts
• [x] All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html
• [x] READMEs, other appropriate docs, JSDocs and swagger/APIs fully updated
• [x] UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required)
• [x] Interactors should validate entities before calling persistence methods
• [x] Code refactored for clarity and to remove any known technical debt
• [x] Deployed to the Court's test environment

[matthopson]

Ahh, this makes so much more sense. It's the secondary document that's the key. Thank you!

[matthopson]

PR to prevent making it to the service step when there's a validation error. https://github.com/ustaxcourt/ef-cms/pull/1128

Another question somewhat related to this: We set a limit on the documentTitle for a secondaryDocument of 500 here: https://github.com/flexion/ef-cms/blob/develop/shared/src/business/entities/EntityValidationConstants.js#L271

But we also have a validation constant defined for DOCUMENT_TITLE at 3,000 characters here: https://github.com/flexion/ef-cms/blob/develop/shared/src/utilities/JoiValidationConstants.js#L23

Should we use this constant (3,000 character doc title) for the secondary document's title as well?

[JessicaMarine]

Should we use this constant (3,000 character doc title) for the secondary document's title as well?

Yes.