Bug: queries to the submissions API endpoint return the child report as well as the correct report.

[jimduff-usds]

Describe the bug I submitted a single HL7 file in staging, then ran the submissions API query. It returned two reports, instead of one.

Impact Anyone using the UI to view lists of submissions will see confusing extra reports. Anyone using the API to retrieve lists of submissions will also see confusing extra reports.

To Reproduce After submitting the one HL7 file, here's the API call I ran:

./prime login --env staging
export TOK=$(cat ~/.prime/accesstoken.json | grep token | cut -d"," -f1 | cut -d":" -f2 | tr -d \")
curl -H "authentication-type: okta" -H "Authorization: Bearer $TOK" https://staging.prime.cdc.gov/api/waters/org/mayo-clinic/submissions"

It should return one result, but it returned two (see below). The API is returning both the original submitted report (928…), and the child “internal CSV format” report that was created from it (77f….). You can see this by looking at the lineage in Staging metabase. The 77f... is erroneous and is a bug. Note that they have the same timestamp. I'm pretty sure this used to work fine a couple months back.

[ {
  "submissionId" : 3154421,
  "timestamp" : "2022-07-26T18:04:42.242Z",
  "externalName" : "mayo1.hl7",
  "id" : "77f3fc3f-d30a-4ae4-9c1d-54a54bdc6f37",
  "topic" : "monkeypox",
  "reportItemCount" : null,
  "sender" : "mayo-clinic",
  "httpStatus" : 201
}, {
  "submissionId" : 3154421,
  "timestamp" : "2022-07-26T18:04:42.242Z",
  "externalName" : "mayo1.hl7",
  "id" : "928ae63d-b363-4a82-b9d6-0e37fbddbc8c",
  "topic" : "monkeypox",
  "reportItemCount" : null,
  "sender" : "mayo-clinic",
  "httpStatus" : 201
}

Expected behavior Calls to the submissions API only return submissions, never any child reports.

Screenshots

Logs

Desktop (please complete the following information):

Smartphone (please complete the following information):

Additional context

• Note that only the original submission has a non-null sending_org in the database, so you could filter on that field. Note that the 'deliveries' query is different - make sure you don't break that query when you fix this one!

[jimduff-usds]

Note: this has nothing to do with async processing -- the data was submitted with the 'sync' processing.

[jimduff-usds]

Here's another example of the impact:

Onboarding MPX Customer has send data to RS and is anxious to know if it worked. They sent an email stating:

I see these responses below:
StatusCode: 201, ReasonPhrase: 'Created' with:
·         "reportId" : "d4479e6d-70d2-45d3-8703-822bc5057207", for LOINC:100383-9
·         "reportId" : "4b8536bb-0aff-4433-afe5-b2eb7c871b22", for LOINC: 100434-0

So I query to find out if it worked:

prime-router % curl -H "authentication-type: okta" -H "Authorization: Bearer $TOK" "https://staging.prime.cdc.gov/api/waters/org/sonic/submissions"

And I confusingly get back four results instead of the two he mentioned:

[ {
  "submissionId" : 3155169,
  "timestamp" : "2022-07-27T22:22:08.540Z",
  "id" : "265579cb-6353-4094-bb53-5382867a21e5",
  "topic" : "monkeypox",
  "reportItemCount" : null,
  "sender" : "sonic",
  "httpStatus" : 201
}, {
  "submissionId" : 3155169,
  "timestamp" : "2022-07-27T22:22:08.540Z",
  "id" : "4b8536bb-0aff-4433-afe5-b2eb7c871b22",
  "topic" : "monkeypox",
  "reportItemCount" : null,
  "sender" : "sonic",
  "httpStatus" : 201
}, {
  "submissionId" : 3155168,
  "timestamp" : "2022-07-27T22:22:06.306Z",
  "id" : "b8975951-3bd7-417d-8e41-c4b55fd621dc",
  "topic" : "monkeypox",
  "reportItemCount" : null,
  "sender" : "sonic",
  "httpStatus" : 201
}, {
  "submissionId" : 3155168,
  "timestamp" : "2022-07-27T22:22:06.306Z",
  "id" : "d4479e6d-70d2-45d3-8703-822bc5057207",
  "topic" : "monkeypox",
  "reportItemCount" : null,
  "sender" : "sonic",
  "httpStatus" : 201
}, {

If the customer were to query this, they would also be confused.

Thanks.