| Issue Number | 5361 |
|---|---|
| Summary | Audio import report appears to stall on PROD |
| Created | 2025-01-06 12:11:45 |
| Issue Type | Bug |
| Submitted By | Osei-Poku, William (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | DEV Verified |
| Resolved | 2025-01-06 18:32:46 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.485402 |
The Audio Import report appears to be stalling on PROD this morning and displays just a handful of documents that have been created or updated. Meanwhile, the interface itself continues to display the zip files and lets you run the report again. I ran the report a couple of hours ago, but it has still not completed.
To reproduce on PROD:
Navigate to the CIAT/OCC menu
Click on the Audio Import report
Click on Submit after the display of the zip files
Notice that in the new page, only 4 documents are displayed as being process
Acceptance criteria:
Navigate to the CIAT/OCC menu
Click on the Audio Import report
Click on Submit after the display of the zip files
A list of media and glossary terms that have been updated should be displayed for review
Please don't run this job again until we track this down. As the display told you each time it was run this morning, it created new Media documents for both of the rows in the _Rev3 workbook. So now you've got 22 Media documents for two MP3 files. And they're all going to be published.
Fixed on CDR DEV. Will work on preparations for testing on DEV tomorrow.
I have installed the test data on the s/FTP server for both DEV and QA. You should be able to see the broken behavior on QA (where the fix has not been installed) and the correct behavior on DEV (where the bug is fixed) by performing the following steps:
Go to CIAT/OCC > Audio > Audio Download
Click Submit
Go to CIAT/OCC > Audio > Audio Review Glossary Term
Click on Week_2099_01.zip
Approve the English pronunciation
Reject the Spanish pronunciation
Click Save
Click on Week_2099_01_Rev1.zip
Approve the Spanish pronunciation
Go to CIAT/OCC > Audio > Audio Import
Click Submit
Note whether both Media documents were created
The test suite has been enhanced to detect a regression for this bug. The test fails on QA and passes on DEV.
Note that I had to switch the configuration for CDR DEV to point to the original s/FTP server. It had instead been connected to the new server which is being tested as a replacement for the current live server, and the directories for the audio files are broken on the new server. This means that if someone points CDR DEV back to the new s/FTP server while that server is still broken, the steps above will fail on DEV as well (but well before you get to step 12).
Test passed on DEV. Thanks!
On QA, it created only one document CDR817140. I assume that because the second document was not created, the program failed on QA.
Another observation is that on DEV, even after the process had completed with the creation of the documents, the zip files continue to remain on the Audio Import page. That is, after I had navigated away and back to the Audio Import page. Should the files be cleared from the Audio Import page after the documents have been created?
Another observation is that on DEV, even after the process had completed with the creation of the documents, the zip files continue to remain on the Audio Import page.
Is the wording of your observation intentional? That is, are you implying that on PROD (and other tiers) the behavior is different?
Should the files be cleared from the Audio Import page after the documents have been created?
Let's drill down into this question. Do you mean: In the past, archive sets which have already gone through a successful import have no longer appeared on the review page. Why are they still appearing now? Or do you mean: Should the requirements be changed so that archive sets no longer appear on the review page after going through a successful import? If the former, a quick review of the pre-Riemann software doesn't show any code which would be doing anything to remove the archive files from which successful imports have been made, other than the fact that as soon as archive files for a newer week are in place, they mask the archive files for previous weeks, so you only see the most recent set of archive files. I will do more digging into the code history, depending on your answers.
Never mind. I wasn't comparing with the behavior of the pre-Riemann software. I was only thought that the file would clear about after a successful run. But now I know 🙂
No, it never has. I went back through the entire 10-year history of
the script, and it has always left the archive in place, to be hoovered
into the JobArchive directory by a scheduled job
eventually, and masked (often before that happens) by the zipfiles for
the newer week's sets.
Verified on DEV again with a larger set of terms. Thanks!
Elapsed: 0:00:00.001684