[ART] Create pilot-2122-backend ADR

[nihil2501]

No description provided.

[raudabaugh]

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?

[nihil2501]

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?

[nihil2501]

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.

[candilemoine]

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.

[nihil2501]

Yeah I think the desired business logic is an open question. One example is what you outlined above. This could be the most simple if when the representative is driven to a declination in this scenario, we don't need extra logic that accounts for the scenario. For example, should the set of declination notifications be different than usual for this scenario?

Another approach would be forcing the impacted POA request into a "soft-terminal" state–some concept like "obsolesced by system" that, for example, we also leverage when newer ARM POA requests come in (the currently proposed business logic says "only one open POA request at a time").

I agree that we should backlog this open question.

From an architectural standpoint, we might eventually need to robustly implement syncing important application state that lives in another system (the established POA in BGS). I think the possible approaches for this are a little messy but still within the realm of viability.

[nihil2501]

And to be clear, the Tyler Tech edge case (and the concomitant external application state synchronization concern) exists independently of this "shallow backend for pilot" proposal.