API-41844: Fix Contestable Issues (Decision Reviews v2) X-VA-Receipt-Date Bug

[kristen-brown]

Summary

This work is behind a feature toggle (flipper): NO

This PR fixes a bug in the Decision Reviews v2 Contestable Issues endpoints, where the consumer received a confusing error message, \"2019-02-19\" is before AMA Activation Date (2019-02-19)., when they provided "2019-02-19" for the X-VA-Receipt-Date header. The only validations for X-VA-Receipt-Date that we were performing were 1) checking for its presence, and 2) checking that it matched the yyyy-mm-dd format. Therefore, this error was being returned from Caseflow itself.

After confirming that the X-VA-Receipt-Date must be 2019-02-20 or later (rather than 2019-02-19, as previously believed), I added a validation for the date on our end, so that we can avoid the confusing error message and also format the validation error to meet our validation error standards. This PR also adds a message to the X-VA-Receipt-Date header in our documentation to specify this date requirement, which wasn't anywhere in our documentation before.

My team (Lighthouse Banana Peels) owns the appeals_api module.

Related issue(s)

• 🎟️ API-41844

Testing done

• New code is covered by unit tests

All affected endpoints were tested locally with different X-VA-Receipt-Date inputs (valid and invalid) using our Appeals API Bruno examples.

Screenshots

What areas of the site does it impact?

This PR impacts the appeals_api module only.

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog (if applicable) – N/A
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

No specific feedback requested for this PR.

[kristen-brown]

These particular changes aren't related to the updates in this PR, but the fields reordered themselves after I ran the rake task that regenerates the documentation. These changes don't harm anything, and they accurately reflect the order of fields returned in the response.

[mathisto]

[kristen-brown]

I found a bug on the Decision Reviews v2 HLR Contestable Issues endpoint (/services/appeals/v2/decision_reviews/higher_level_reviews/contestable_issues/{benefit_type}) that doesn't occur on the general DR v2 Contestable Issues endpoint (/services/appeals/v2/decision_reviews/contestable_issues/{decision_review_type}), since the latter endpoint validates the headers against the schema, but the former does not (inherits from the AppealsApi::V1::DecisionReviews::BaseContestableIssuesController, which is older). The bug occurred when an X-VA-Receipt-Date header was passed but the contents were an invalid date. The code on L37 was failing to parse the date, and the endpoint was responding with a 500 error. By rescuing the error, I can return a 422 response instead, which is more appropriate.

I started to go down the path of handling this in a more holistic and clean way (I wasn't sure why this endpoint wasn't validating the headers against the schema and the other one was), but the scope spiraled quickly and I didn't want to risk breaking the API contract for this endpoint. Since this endpoint will soon be replaced by the Appealable Issues v0 API, I landed on this simpler (but less ideal, code style-wise) approach. I chose not to save the error detail in our I18n translation file because I don't want to encourage this pattern going forward. (Headers and params should always be compared against the schema in the future.)

[kristen-brown]

This is ready for re-review!