[ART] Create pilot-2122-backend ADR #96223
Conversation
products/accredited-representative-facing/engineering/ADRs/pilot-2122-backend.md
Show resolved
Hide resolved
products/accredited-representative-facing/engineering/ADRs/pilot-2122-backend.md
Show resolved
Hide resolved
|
|
||
| Technical complexity will be greatly reduced for the pilot. Error handling and monitoring will be simplified, and we will have more control over UX responsiveness. | ||
|
|
||
| We'll separately prioritize and roadmap adding the additional Lighthouse calls originally called for in the technical design. In this ADR, we're not proposing that we won't later add those Lighthouse calls. We're also not proposing a particular timeline for adding those calls. We'll depend on our Product Owner, Engineering Lead, and other VA partners for future decisionmaking and discussion there. |
There was a problem hiding this comment.
I think it's worth discussing the risks of skipping CorpDB for request storage in our initial release. E.g. might there be conflicts with a 3rd party tool posting to /forms/2122 on the v1 API? Do we expect 3rd party tools to store requests in our database as well?
There was a problem hiding this comment.
Response from Alex (doesn't have GH access to reply himself yet):
might there be conflicts with a 3rd party tool posting to /forms/2122 on the v1 API?
Scenario:
- Someone opens a POA request for organization A
- They then file a 21-22 using Tyler Tech or mail for organization B, which is processed by VA and changes their POA to organization B
- A POA manager from organization A goes to view POA requests
With the design in this ADR, the POA manager from organization A should then be able to accept/reject the request, potentially overwriting POA from organization A to organization B.
It's possible that the LH APIs would have handled this situation differently — I'm not aware if they were designed to — but they could, when receiving a 21-22 via LH API, close any open POA requests from other organizations.
However, whatever LH APIs did would not apply to mailed in forms, which don't use LH APIs and should still be able to overwrite.
It's not clear to me what the best system behavior should be in the above scenario.
Hopefully expiring POA requests after a period of time (currently 60 days) and adding the expiration period in copy when a user files a request will eliminate much of the possible confusion.
@raudabaugh @ITS-mharlow @nihil2501 @holdenhinkle @oddball-lindsay — anything I'm missing?
There was a problem hiding this comment.
The most obvious race condition that comes to mind is:
ARM POA requested date < Tyler Tech POA established date
For this scenario, I think we have the opportunity to query for this condition during individual POA request operations (POA request detail view & POA request acceptance). It is also possible to poll on some cadence (even a relaxed one) so that the POA request list view doesn't misreport the situation often.
There was a problem hiding this comment.
On Alex Prokop's behalf
@nihil2501 — good point — just to confirm what I think you're suggesting:
- The POA manager clicks into a particular POA request on ARP
- We load POA history in that card view
- If we see that POA was updated for the requester since the POA request was filed, we display an extra warning to the POA manager before we let them accept the request
This might be the most optimal way to handle this situation regardless, as long as we don't have reason to mistrust POA manager motivations. It would potentially come at the cost of an extra trip to BGS which would add slowness to each request.
I suggest we file this in the backlog and decide whether to prioritize it later.
No description provided.