LG-14317 Fix Cancelled and Failed enrollments put users in broken account state

[gina-yamada]

🎫 Ticket

LG-14317 Cancelled and Failed enrollments put users in broken account state

🛠 Summary of changes

• When enrollments get updated for the x4 scenarios below, update the pending_enrollment.profile.in_person_verification_pending_at on the profile to be nil

📜 Testing Plan

Scenario 1: Unsupported ID Type
Create an enrollment- get to Ready to Verify (barcode page)
In your terminal open the rails console

e = InPersonEnrollment.last
res = JSON.parse(UspsInPersonProofing::Mock::Fixtures.request_passed_proofing_unsupported_id_results_response)
job = GetUspsProofingResultsJob.new
job.instance_variable_set('@enrollment_outcomes', { enrollments_passed: 0, enrollments_failed: 0, enrollments_e
rrored: 0, enrollments_expired: 0, enrollments_checked: 0 })
job.send(:process_enrollment_response, e, res)

Verify that the enrollment is updated to status is failed.
e

Verify that the profile associated with the enrollment is not active (active = false), in_person_verification_pending_at is nil, and the deactivation_reason is verification_cancelled.
e.profile

Refresh from the Ready to Verify View (Barcode code page). Confirm you are taken to the account view.
Sign out.
Sign-in via Login.gov (Verify application navigates to the account page). Sign out.
Sign-in via Sinatra (Verify application navigates to the verification welcome page ie: /verify/welcome)
Step through IPP to successfully create a barcode

Scenario 2: Handle Unexpected Response
Create an enrollment- get to Ready to Verify (barcode page)
Make temporarily updates to app/services/usps_in_person_proofing/mock/proofer.rb commenting out the original request_proofing_results method to the following:

def request_proofing_results(_enrollment)
  body = JSON.parse(
    Fixtures.request_unexpected_invalid_enrollment_code_response
  )
  response = { body: body, status: 400 }
  raise Faraday::BadRequestError.new('Bad request error', response)
end

In your terminal open the rails console
e = InPersonEnrollment.last

Copy the enrollment code.

Update the enrollment code in
app/services/usps_in_person_proofing/mock/responses/request_unexpected_invalid_enrollment_code_response.json

job = GetUspsProofingResultsJob.new
job.instance_variable_set(
'@enrollment_outcomes', { 
enrollments_passed: 0, 
enrollments_failed: 0, 
enrollments_errored: 0, 
enrollments_expired: 0, 
enrollments_checked: 0 })
job.send(:check_enrollment, e)

Verify that the enrollment is updated to status is cancelled.
e

Verify that the profile associated with the enrollment is not active (active = false), in_person_verification_pending_at is nil, and the deactivation_reason is verification_cancelled.
e.profile

Refresh from the Ready to Verify View (Barcode code page). Confirm you are taken to the account view.
Sign out.
Sign-in via Login.gov (Verify application navigates to the account page). Sign out.
Sign-in via Sinatra (Verify application navigates to the verification welcome page ie: /verify/welcome)
Step through IPP to successfully create a barcode

After, be sure to change code back in...

• app/services/usps_in_person_proofing/mock/proofer.rb
• app/services/usps_in_person_proofing/mock/responses/request_unexpected_invalid_enrollment_code_response.json

Scenario 3: Handle Failed Status
Create an enrollment- get to Ready to Verify (barcode page)
In your terminal open the rails console

e = InPersonEnrollment.last
res = JSON.parse(UspsInPersonProofing::Mock::Fixtures.request_failed_proofing_results_response)
job = GetUspsProofingResultsJob.new
job.instance_variable_set('@enrollment_outcomes', { enrollments_passed: 0, enrollments_failed: 0, enrollments_e
rrored: 0, enrollments_expired: 0, enrollments_checked: 0 })
job.send(:process_enrollment_response, e, res)

Verify that the enrollment is updated to status is failed.
e

Verify that the profile associated with the enrollment is not active (active = false), in_person_verification_pending_at is nil, and the deactivation_reason is verification_cancelled.
e.profile

Refresh from the Ready to Verify View (Barcode code page). Confirm you are taken to the account view.
Sign out.
Sign-in via Login.gov (Verify application navigates to the account page). Sign out.
Sign-in via Sinatra (Verify application navigates to the verification welcome page ie: /verify/welcome)
Step through IPP to successfully create a barcode

Scenario 4: Handle Unsupported Secondary ID Type
Create an enrollment- get to Ready to Verify (barcode page)
In your terminal open the rails console

e = InPersonEnrollment.last
res = JSON.parse(UspsInPersonProofing::Mock::Fixtures.request_passed_proofing_secondary_id_type_results_response)

job = GetUspsProofingResultsJob.new
job.instance_variable_set('@enrollment_outcomes', { enrollments_passed: 0, enrollments_failed: 0, enrollments_e
rrored: 0, enrollments_expired: 0, enrollments_checked: 0 })
job.send(:process_enrollment_response, e, res)

Verify that the enrollment is updated to status is failed.
e

Verify that the profile associated with the enrollment is not active (active = false), in_person_verification_pending_at is nil, and the deactivation_reason is verification_cancelled.
e.profile

Refresh from the Ready to Verify View (Barcode code page). Confirm you are taken to the account view.
Sign out.
Sign-in via Login.gov (Verify application navigates to the account page). Sign out.
Sign-in via Sinatra (Verify application navigates to the verification welcome page ie: /verify/welcome)
Step through IPP to successfully create a barcode

Notes:
We used this doc to work through changes.

[eileen-nava]

It feels weird to me to use a method named deactivate_due_to_ipp_expiration in scenarios where the in_person_enrollment didn't actually expire. Maybe we could rename deactivate_due_to_ipp_expiration to something more general, like deactivate_during_ipp?

I am slightly concerned that down the road, developers who are new to the project might confuse deactivate_during_ipp and deactivate_for_in_person_verification. The methods have opposite effects on the in_person_verification_pending_at profile timestamp, but similar names. The acronym and full name discrepancy is also not great.

Please let me know if you can think of a clearer name than deactivate_due_to_ipp!

[eileen-nava]

Is it possible to update the :in_person_enrollment :pending factory trait and set the profile in_person_verification_pending_at timestamp in there, maybe similar to what Andrew did here in the users factory?

I know we have a ticket to clean up the in_person_enrollments factory and am okay with also doing the suggested work while working on that ticket.

[shanechesnutt-ft]

I added this to the in_person_enrollment factory. see commit

[eileen-nava]

Thanks for adding that, @shanechesnutt-ft!

[jennyverdeyen]

I ran through each testing scenario - I think there was a small error in Scenario 1 (unsupported ID type) where you meant to specify request_passed_proofing_unsupported_id_results_response as the mock fixture to use. With that assumption, I ran all the scenarios and everything behaved as expected. The broken account state doesn't occur.

Tests pass!

I like the improved method name for deactivate_due_to_in_person_verification_cancelled!

Great work, LGTM!

[gina-yamada]

It feels weird to me to use a method named deactivate_due_to_ipp_expiration in scenarios where the in_person_enrollment didn't actually expire. Maybe we could rename deactivate_due_to_ipp_expiration to something more general, like deactivate_during_ipp?

I am slightly concerned that down the road, developers who are new to the project might confuse deactivate_during_ipp and deactivate_for_in_person_verification. The methods have opposite effects on the in_person_verification_pending_at profile timestamp, but similar names. The acronym and full name discrepancy is also not great.

Please let me know if you can think of a clearer name than deactivate_due_to_ipp!

@eileen-nava Are you okay with the new name deactivate_due_to_in_person_verification_cancelled?

[eileen-nava]

@eileen-nava Are you okay with the new name deactivate_due_to_in_person_verification_cancelled?

@gina-yamada Yes, I am okay with the new name deactivate_due_to_in_person_verification_cancelled.
Not sure if you saw, but I responded here and also resolved the relevant comments.

I think we can merge this PR now. Great work!