cleanup

docs/all.md

@@ -55,6 +55,9 @@
 - [Data Storage Policies \& Procedures](#data-storage-policies--procedures)
   - [Potential PII Locations](#potential-pii-locations)
   - [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
@@ -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
 
 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>"
+```