API-45023-recache-mpi-after-icn

[rockwellwindsor-va]

Summary

• re caches MPI data once we have the ICN
• adds method to enable re fetching the cache on MPI data
• adds flipper for add_person_proxy update
  *. Adjusts related tests

Related issue(s)

API-45023

Testing done

• New code is covered by unit tests

Testing Notes

• This is perhaps more easily seen via manual testing
• To test manually send in a v1 request (2122 and 526 were both tested locally by me, any should work though)
• Place a debugger to stop the app flow inside the veteran_from_headers method before recache_mpi_data is called
• Observe the redis cache that there is a key related to the veteran in the headers, the key should use the SSN as it value so something like this should exist (change the SSN based on your test veteran)
  • KEYS * => mpi-profile-response:796127677 , where 796127677 is the SSN of your test veteran
  • Then allow the app to continue to run through its workflow
  • AFTER recache_mpi_data gets called you should have a new key in Redis for the same test veteran in the headers but this one should have the ICN as its key
  • KEYS * => mpi-profile-response:1012861229V078999
  • Once you have that key then you can test the add_person_proxy gets called and is successful.
• Testing add_person_proxy
  • You need to get the value of the Redis cache and remove the participant_id from it.
  • GET mpi-profile-response:1012861229V078999
  • Remove the participant ID from the object (I left in the "" but either should work)
  • copy that object with participant_id removed
  • SET mpi-profile-response:1012861229V078999 <object with participant_id removed pasted here>
  • Now when you run the same submit you can observe that the headers workflow gets called and built
  • After recache_mpi_data gets called make sure to verify the Redis cache is still missing the participant ID, if it has it just re set it again without it.
  • Debugging inside validate_veteran_identifiers you should be able to see it get to line 88.
  • Debugging after line 88 you should see a successful response and observe the Redis cache has the participant ID.
  • Allow the workflow to continue and it should proceed past the application controller into whatever form you submitted to.

What areas of the site does it impact?

modified:   modules/claims_api/app/controllers/claims_api/v1/application_controller.rb
modified:   modules/claims_api/app/models/claims_api/veteran.rb

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)
• 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

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[stiehlrod]

Saw the redis cache before and after the new re-cache method. LGTM