[Spike] VEDUHSF Fixes -LH migration for evidence uploads error responses

[lisacapaccioli]

Most of the fixes for the silent upload failures are going to require the LH migration for evidence uploads. Before we can plan the fixes we need to know more about the LH Migration endpoint.

Example

• [ ] When will the submit endpoint be ready?
• [ ] When will the validation endpoint be ready?
• [ ] Are the documented example responses correct?
• [ ] How big do we think this is going to be?
• [ ] Do we have the requirements? (what will it allow vs. not allow - I think we have most of these)
• [ ] Decrypting passwords - will our existing flow work with this endpoint? (dependent on other spike)

Probably way more than I can think of right now.

Notes

• link to the slack message that Thomas started on LH Migration for evidence uploads
• Nathan might have some background information as well
• There are LH meetings if you are not already on, we should add you (Nathan could forward them to you)
• Check with Thomas as well, he might also have some meetings that we need to check into

[ajones446]

Gathering context for LH requirements -

1: Summary of June 17 slack convo

VA.gov should use the Benefits Documents API for uploading documents related to claims. Documentation here: https://developer.va.gov/explore/api/benefits-documents/docs?version=current

Requirements we should check before sending to Lighthouse

• Allowed file type: .pdf, .jpg, .jpeg, .png, .gif, .bmp, or .txt
• Max file size: 150MB
• Max filename size: 256 character limit (limit includes the extension, special characters are allows in filename - e.g, lisa;capaccioli.pdf, lisa's medical record.pdf, lisa/VA document/disability.pdf)
• Correct filename mime type: The file extension in the filename has to match uploaded mime type (e.g, the file name is “test.txt”, but the media type is PDF will produce a 400 error.)
• Content is ASCII encoded (no non-ASCII characters allowed)
• No viruses are found
• Locked PDFs are able to be unlocked and stamped
• The fileNumber/participantId belongs to the claimId

### 2: Other requirements from Benefits Intake API documentation There is no limit on the number of files a payload can contain, but file size and page dimension limits do apply. - Uploaded PDFs can't be larger than 78" x 101". - Uploaded PDFs can't exceed 100 MB. (*this is different than max file size listed above) - The entire payload can't exceed 5 GB.

To prevent submission delays and errors: - Be sure to validate all metadata fields against their data requirements as defined in the DocumentUploadMetadata schema before submitting your payload. - The businessLine field is optional, but when included, it will ensure the fastest possible processing. If not specified, businessLine will default to CMP, the business line for Compensation requests. - The POST /uploads/validatedocument endpoint can be used to ensure individual PDF documents meet system requirements prior to submission. (*this only appears to be for PDFs_)

UPDATE: I copied those requirements from the wrong API earlier - for Benefits INTAKE. We will be using the Benefits DOCUMENTS API https://developer.va.gov/explore/api/benefits-documents/docs?version=current

[ajones446]

For the final form submit, we will use the LH benefits-document API POST /documents endpoint. That endpoint is ready - the mobile team has been using it.

Updates from 8.27 slack convo

• A 200 response from POST /documents is only an acknowledgment of receipt, not that it has made it to the next destination
• The LH benefits-document API POST /documents/validate will not be validate the actual documents. It only validates a dependent submitting user's permission to access the veteran's eFolder.

[ajones446]

Note from the mobile team about their LH migration experience: https://github.com/department-of-veterans-affairs/va.gov-team/issues/88297#issuecomment-2230998143, probably related to the requirement The fileNumber/participantId belongs to the claimId

Only minor gotcha is that the user must be a Veteran or a dependent of a deceased Veteran in order to upload files. If they are a dependent of a living Veteran than you will get back a 4XX error

[lisacapaccioli]

@ajones446 I'm assuming there is something in the User Information that distinguishes a dependent and whether the Veteran is living or deceased and that they check against the fileNumber/participantId? We'll have to remember to ask OCTO if this would ever be a problem when filing a disability claim. I don't know if dependents are allowed to file them (my assumption would be no).