BDD Bug - FIX - validateSeparationDate improperly enforcing past date

[mchae-nava]

On-hold - waiting for new case where we can see form data

Case # 09964639 Case # 10002612 Case # 10054426 T3 BDD Claim issue

Issue Description

A small subset of consumers going through the BDD form incorrectly see a 'Your separation date must be in the past' validation error when submitting a date of discharge. The date of discharge should be between 90 - 180 days in the future.

Slack thread Previous issue + notes deliverable

From previous notes:

• Issue is blocking to consumers who experience
• Issue appears to have a low repro rate (percentage of 3% of submissions), but may involve survivorship bias; can confirm with access to consumer data
• DataDog, Sentry, and Rails console prod access are in the pipe

Resolution notes:

• Application ID 6882359 was used; looking this up may reveal some more info
• In this case, the application ID was also the inProgressFormId
• The cause comes from conditional on line 444 in validation.js, validateSeparationDate in the vets-website repo, meaning this is a frontend validation issue
• Line 367 in src/applications/disability-benefits/all-claims/utils/index.jsx may also shed some light if cross-referenced with a use case
• Called through militaryHistory, which is evoked in forms
• User is expecting to file a BDD claim, isBDD is expected to be true
• At some point, isBDD is not evaluating correctly
• Similarly to the future DOC bug, there appears to be some entanglement with isReserves and the other conditionals
• No UX changes needed as of now

Repro steps

• Login to va.gov
• Click 'sign in', in the modal select ID.me
• Navigate straight to the form wizard: /disability/file-disability-claim-form-21-526ez/start
• “Are you on active duty right now?" > “Yes” > set a discharge date at least 90-180 days in the future > File a BDD claim online
• On step 1 of 5: Veteran Details under ‘Service end date’, select a date that is at least 90-180 days in the future
• You will see a validation error saying ‘Your separation date must be in the past’

Noting that other users have reported the same issue; they have reported the same repro steps (sans dev specific steps), meaning the problem likely has to do with data, and not the use case

---

Tasks

• [ ] Confirm consumer data on user identified in the repro steps
• [ ] Implement solution to the validation

Acceptance Criteria

• [ ] Issue does not reproduce for users with data matching the repro case

[RakshindaAslam]

cc @RakshindaAslam

[Kimberley2019]

Tracking purposes for our team: https://app.zenhub.com/workspaces/contact-center-62cdd9546ec1530018209672/issues/gh/department-of-veterans-affairs/va.gov-team/57943

[mchae-nava]

@sethdarragile6 Before prod approval, these are some failed repro attempts:

• Control run using a BDD flow, dates validate properly
• From /start, started a BDD form, went back to /start, initiated a non-BDD flow, but then resumed the BDD form
• Traced isBDD and to any sources that may cause it to update or change (unfinished)

Until prod access:

• Continue seeing where isBDD might be updated, this extends to appStateData
• Find someone with prod access, get info on repro'ing users, their form data, service periods

[mchae-nava]

@Kimberley2019 Is there a way we can view info tied to the cases listed in the description? If not, can you give us the names and form IDs associated with the repro cases? Can we get that info via encrypted email? It'll be very helpful for looking up data and verifying the fix

[sethdarragile6]

@mchae-nava so we know that Case # 10002612 is different than the other 2 (different repro steps), but is the error message the same? Doesn't seem to be a screenshot on the ticket (presumably because of PII?). Also, do we have tickets for the other 2 cases?

[sethdarragile6]

@RakshindaAslam @mchae-nava per our conversation in stand-up, moving this back to the backlog for now. We looked into the current data for cases 09964639 and 10054426- the former had a Form526Submission record (meaning the form was eventually submitted and we can't repro the original error state) and the latter had neither a Form526Submission record nor an InProgressForm record. Ideally, if we had an InProgressForm record, we could use that to at least better identify the source of the problem, if not repro it.

[RakshindaAslam]

cc @lydiahooper

[sethdarragile6]

found an old va.gov email from Kimberley Daniels from May 22 that somehow just missed until now. she provides ICNs for each of these cases:

• case 09964639: 1039207877V213566
• case 10054426: 1029366282V746548