[ARP PoA submission] (#2) Lighthouse 2122 submission (#99310)

[pixiitech]

This is PR No. 2 of a stack concerning ticket #99310 and #101919
This code handles the methods added to consume the LH API for the form submission and RSpec tests. The controller action, and code that creates our local PowerOfAttorneyFormSubmission object are being moved to the next PR.

Summary

• This work is behind a feature toggle (flipper): YES/NO Yes

• (Summarize the changes that have been made to the platform)

• Updated endpoint for submission of 2122 form to submit decision to Lighthouse

• (If bug, how to reproduce) feature

• (What is the solution, why is this the solution?)

• ⭐ Implement POA Establishment Method In Lighthouse API Client va.gov-team#99310

• (Which team do you work for, does your team own the maintenance of this component?) ARF

• (If introducing a flipper, what is the success criteria being targeted?)

Related issue(s)

• Link to ticket created in va.gov-team repo OR screenshot of Jira ticket if your team uses Jira
• ⭐ Implement POA Establishment Method In Lighthouse API Client va.gov-team#99310
• Link to previous change of the code/bug (if applicable)
• Link to epic if not included in ticket

Testing done

• New code is covered by unit tests

• Describe what the old behavior was prior to the change

• method did not exist

• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing

• If this work is behind a flipper:

  • Tests need to be written for both the flipper on and flipper off scenarios. Docs.
  • What is the testing plan for rolling out the feature?

Screenshots

Note: Optional

What areas of the site does it impact?

(Describe what parts of the site are impacted andifcode touched other areas)
AR portal

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?

[nihil2501]

Don't use double (which defeats the request from actually happening and getting captured by VCR). Also use full match_requests_on options (e.g. body explained a little here in weirdly organized VCR docs).

Actually, you'd probably run into a really crappy way in which bearer token filtering defeats the headers part of the VCR matching. But this is an example where the headers aren't worth matching because they aren't dynamic in a way that is correlated to the program's input. So you could leave headers out of the matching when that bearer token filtering happens.

Full matching (or as full as you can get) and asserting about the entire response together constitute a test that fully checks inputs and outputs. All this is the best practice way to do VCR based specs (which is why we have a spec helper for default full matching in a forthcoming PR).

[nihil2501]

This double is stopping a VCR-mediated request from being made. I think we would completely test this functionality with just using using VCR with strictest request matching and not doing the extra work of making these manual receive expectations.

You can see what is meant by "strictest request matching" here in an spec helper we're adding to the ARP module in an upcoming PR (we have a tiny fix PR that adds body to the request matching which we forgot first time around).

Since this is outside the ARP module (and that code wasn't introduced yet anyway), you could just merge in these VCR options directly:

{ match_requests_on: %i[method uri headers body] }

Then we can remove the double.

[nihil2501]

Minor point but removing the .yml extension in cassette name will result in .yml cassette rather than _yml.yml cassette.

[nihil2501]

Minor point but removing the .yml extension in cassette name will result in .yml cassette rather than _yml.yml cassette.

[nihil2501]

We should make a complete assertion about the entire response object and status and stuff here.

[nihil2501]

LGTM