Jadudm/automatic uei waiver#4872
Conversation
I really don't know what we want to put for the name of the entity. It might be better to leave blank. I'm going to move this to a draft PR for others to put eyes on.
|
Terraform plan for meta No changes. Your infrastructure matches the configuration.✅ Plan applied in Deploy to Development and Management Environment #989 |
|
Terraform plan for dev Plan: 1 to add, 0 to change, 1 to destroy.Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
# module.dev.module.cors.null_resource.cors_header must be replaced
-/+ resource "null_resource" "cors_header" {
!~ id = "*******************" -> (known after apply)
!~ triggers = { # forces replacement
!~ "always_run" = "2025-04-16T11:44:09Z" -> (known after apply)
}
}
Plan: 1 to add, 0 to change, 1 to destroy.✅ Plan applied in Deploy to Development and Management Environment #989 |
|
This pull request is not up to date with main. Please merge main into this brach or rebase this branch onto main. This PR should not be approved until all status checks pass. If you see this message, please rerun all status checks before merging. |
Adding a check to see the waiver was granted/generated.
|
This pull request is not up to date with main. Please merge main into this brach or rebase this branch onto main. This PR should not be approved until all status checks pass. If you see this message, please rerun all status checks before merging. |
Because we allow a 403/404, we need to make sure we match the schema here.
|
@jadudm class MockResponse:
def __init__(self, status_code, reason=None, json_data=None):
self.status_code = status_code
self.reason = reason or self.get_reason_phrase(status_code)
self._json = json_data or {}
def json(self):
return self._json
...
...
...
resp, error = call_sam_api(SAM_API_URL, api_params, api_headers)
resp = MockResponse(403) # Simulating a 403 On the UI side, after the pop-up prompting me to input the entity name appeared, I clicked “Cancel,” then repeated the same steps three times. On the third attempt, I clicked OK and noticed that it created three |
Add logging as well.
|
This pull request is not up to date with main. Please merge main into this brach or rebase this branch onto main. This PR should not be approved until all status checks pass. If you see this message, please rerun all status checks before merging. |
|
I'm unsure how to easily defer the waiver grant; that would involve holding some state to a point in the future. I can avoid granting a second waiver if an active waiver exists for the UEI in question, however. I believe my push fixes this problem, and multiple passes through the exemption process no longer create multiple waivers. In other words, I still auto-issue the waiver at the moment that the failure happens. But, it will no longer issue multiple waivers. The wavier duration was reduced from 365 days to 30 days, because it shouldn't be necessary to issue such a long-duration waiver for a UEI. |
|
sambodeme
left a comment
sambodeme
left a comment
There was a problem hiding this comment.
This updated version does not duplicate the waiver record until it expires. Works fine
2 participants
Haiku-length summary
If SAM is away
The audits must flow anon
Grant waivers forthwith
Description
This PR catches HTTP responses from SAM.gov in the set
{401, 403, 404, 405, 406, 410, 418, 429, 451}, which would occur if we had an API key that was no longer valid or if SAM.gov was offline. (Several of the responses are highly unlikely, but we handle them "just in case.") Currently, when this occurs, users of the FAC can no longer create audits. We have decided we must more gracefully handle SAM.gov errors, and are going to automatically issue a waiver (and log/provide an auditable trail) when we encounter this situation.This PR also brings in the ADR marking this decision.
Questions
uei.py) That is, should we handle conditions where SAM is offline the same way (a 404)?To do
PR Checklist: Submitter
maininto your branch shortly before creating the PR. (You should also be mergingmaininto your branch regularly during development.)git status | grep migrations. If there are any results, you probably need to add them to the branch for the PR. Your PR should have only one new migration file for each of the component apps, except in rare circumstances; you may need to delete some and re-runpython manage.py makemigrationsto reduce the number to one. (Also, unless in exceptional circumstances, your PR should not delete any migration files.)PR Checklist: Reviewer
make docker-clean; make docker-first-run && docker compose up; then rundocker compose exec web /bin/bash -c "python manage.py test"The larger the PR, the stricter we should be about these points.
Pre Merge Checklist: Merger
-/+ resource "null_resource" "cors_header"should be destroying and recreating its self and~ resource "cloudfoundry_app" "clamav_api"might be updating itssha256for thefac-file-scannerandfac-av-${ENV}by default.main.