mirror of
https://github.com/GSA/notifications-api.git
synced 2026-08-24 00:06:16 -04:00
cleanup
This commit is contained in:
25
docs/all.md
25
docs/all.md
@@ -55,6 +55,9 @@
|
|||||||
- [Data Storage Policies \& Procedures](#data-storage-policies--procedures)
|
- [Data Storage Policies \& Procedures](#data-storage-policies--procedures)
|
||||||
- [Potential PII Locations](#potential-pii-locations)
|
- [Potential PII Locations](#potential-pii-locations)
|
||||||
- [Data Retention Policy](#data-retention-policy)
|
- [Data Retention Policy](#data-retention-policy)
|
||||||
|
- [Debug messages not being sent](#debug-messages-not-being-sent)
|
||||||
|
- [Getting the file location and tracing what happens](#getting-the-file-location-and-tracing-what-happens)
|
||||||
|
- [Viewing the csv file](#viewing-the-csv-file)
|
||||||
|
|
||||||
|
|
||||||
# Infrastructure overview
|
# Infrastructure overview
|
||||||
@@ -1224,3 +1227,25 @@ Data Retention Policy
|
|||||||
Seven (7) days by default. Each service can be set with a custom policy via `ServiceDataRetention` by a Platform Admin. The `ServiceDataRetention` setting applies per-service and per-message type and controls both entries in the `notifications` table as well as `csv` contact files uploaded to s3
|
Seven (7) days by default. Each service can be set with a custom policy via `ServiceDataRetention` by a Platform Admin. The `ServiceDataRetention` setting applies per-service and per-message type and controls both entries in the `notifications` table as well as `csv` contact files uploaded to s3
|
||||||
|
|
||||||
Data cleanup is controlled by several tasks in the `nightly_tasks.py` file, kicked off by Celery Beat.
|
Data cleanup is controlled by several tasks in the `nightly_tasks.py` file, kicked off by Celery Beat.
|
||||||
|
|
||||||
|
|
||||||
|
# Debug messages not being sent
|
||||||
|
|
||||||
|
|
||||||
|
## Getting the file location and tracing what happens
|
||||||
|
|
||||||
|
|
||||||
|
Ask the user to provide the csv file name. Either the csv file they uploaded, or the one that is autogenerated when they do a one-off send and is visible in the UI
|
||||||
|
|
||||||
|
Starting with the admin logs, search for this file name. When you find it, the log line should have the file name linked to the job_id and the csv file location. Save both of these.
|
||||||
|
|
||||||
|
In the api logs, search by job_id. Either you will see evidence of the job failing and retrying over and over (in which case search for a stack trace using timestamp), or you will ultimately get to a log line that links the job_id to a message_id. In this case, now search by message_id. You should be able to find the actual result from AWS, either success or failure, with hopefully some helpful info.
|
||||||
|
|
||||||
|
## Viewing the csv file
|
||||||
|
|
||||||
|
If you need to view th questionable csv file, run the following command:
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
cf run-task notify-api "flask command download_csv_file_by_name -f <file location found in admin logs>"
|
||||||
|
```
|
||||||
|
|||||||
@@ -624,12 +624,10 @@ def show_mangled_number_clues(number):
|
|||||||
|
|
||||||
def validate_phone_number(number, international=False):
|
def validate_phone_number(number, international=False):
|
||||||
if (not international) or is_us_phone_number(number):
|
if (not international) or is_us_phone_number(number):
|
||||||
print("FAST EXIT")
|
|
||||||
return validate_us_phone_number(number)
|
return validate_us_phone_number(number)
|
||||||
|
|
||||||
try:
|
try:
|
||||||
parsed = phonenumbers.parse(number, None)
|
parsed = phonenumbers.parse(number, None)
|
||||||
print("PARSED")
|
|
||||||
if parsed.country_code != 1:
|
if parsed.country_code != 1:
|
||||||
raise InvalidPhoneError("Invalid country code")
|
raise InvalidPhoneError("Invalid country code")
|
||||||
number = f"{parsed.country_code}{parsed.national_number}"
|
number = f"{parsed.country_code}{parsed.national_number}"
|
||||||
|
|||||||
Reference in New Issue
Block a user