BUG: 500 status response on when updating agencies with non-unique values

[TylerHendrickson]

Description: This issue is similar to #1376, but relates to scenarios where users are attempting to update an existing agency rather than create a new one. Although the queries issued to Postgres are different, the same unique constraint violation errors are thrown (depending on whether the request attempted to set the agencies name or code to a non-unique value, the UPDATE query violates the agencies_tenant_id_name_unique or agencies_tenant_id_code_unique unique constraints, respectively). As with #1376, the UI does not provide any indication that a problem occurred, although in this case the modal closes upon form submission, making the error even harder to detect for the end-user.

Steps to reproduce:

1. Login as a user with permission to create and update agencies (e.g. tenant admin).
2. Create a new agency for the tenant, providing a valid and unique name (ex. ABC Agency) and code (ex. ABC).
3. Create another new agency for the tenant, also providing a valid and unique name (ex. DEF Agency) and code (ex. DEF).
4. Ensure that the browser's developer console is recording requests, and attempt to edit the second agency (ex. DEF Agency) to a name that is not unique to the tenant (ex. ABC Agency). Observe that the modal closes and that no error is conveyed to the user. Also observe that the PUT /api/organizations/:organizationId/agencies/name/:agency request issued upon form has a status code of 500.
5. Attempt to edit the agency once more, this time by setting its code to a value that is not unique to the tenant (ex. ABC). Again, observe that the modal closes and that no error is conveyed to the user. Also observe that the PUT /api/organizations/:organizationId/agencies/code/:agency request issued upon form has a status code of 500.

Impacts:

• Suboptimal user experience.
• Increased noise in our service monitors.

Desired behavior:

• The server should handle the errors and respond with a status code of 400 (Bad Request).
• The response data should also contain text that helps communicate the nature of the problem to the user.

Implementation details:

• Update the behavior of the PUT /api/organizations/:organizationId/agencies/name/:agency and PUT /api/organizations/:organizationId/agencies/code/:agency API endpoints to catch unique constraint violation errors encountered when attempting to persist a new agency to the DB, and handle those errors by issuing a 400 response that conveys the nature of the problem.
• Update the UI to react appropriately when (400 status) responses containing errors are received by the client upon form submission.

[TylerHendrickson]

cc @caitlinwinner for input on how errors should behave in the UI.

[caitlinwinner]

@agn-dsgn

[agn-dsgn]

CC: @caitlinwinner @TylerHendrickson Also recommended for: #1376

Design recommendations My recommendation from the design side is to throw an error immediately upon user input, BEFORE they hit submit.

We should use the current pattern, wherein if any input field in the modal has an error, the "OK" (save) button is disabled.

Whenever possible we should strive to prevent user error as early as possible to prevent extra time and effort on the user's part.

Here's how that would look (Imagine each input field is improperly filled out)

Text An agency with that name already exists An agency with that code already exists

---

In ARPA, we already throw an error post-submission. While not ideal this could be a backup solution for Grants Finder as well. We could use the alert pattern within the modal in this case.

[agn-dsgn]

Also note, if we must throw other errors with these inputs, assume we'll throw them first, letting users address each sequentially.

Error order of operations:

• Invalid entry (if restrictions to entry format)
• Duplicate entry (eg name already exists) IF entry is valid

[caitlinwinner]

@TylerHendrickson are the above mocks sufficient?