ETT-1411: additional error handling and matomo custom events#202
ETT-1411: additional error handling and matomo custom events#202carylwyatt merged 1 commit intomainfrom
Conversation
| clearInterval(trackerInterval); | ||
| trackerInterval = null; | ||
| modal.hide(); | ||
| if (closeDownloadModal) modal.hide(); |
There was a problem hiding this comment.
I only want to hide the modal if the user clicks the Cancel button. I needed a way to send the cancel callback without closing the modal, so this I added a conditional for that here.
| numAttempts += 1; | ||
| errorCount++; | ||
|
|
||
| if (progressError) { |
There was a problem hiding this comment.
When there's an error with /imgsrv/download-status update the UI and clear the trackerInterval.
| let percent; | ||
| let current = data.status; | ||
| if (current == 'EOT' || current == 'DONE') { | ||
| if (current == 'EOT' || (current == 'DONE' && data.current_page == -1)) { |
There was a problem hiding this comment.
Scenario 1: The real DONE status is always accompanied by a current_page of -1, so I added that to the "ready for download" conditional.
| percent = 100; | ||
| downloadInProgress = false; | ||
| HT.live.announce(`All done! Your ${formatTitle[format]} is ready for download.`); | ||
| } else if (current == 'DONE' && !data.current_page) { |
There was a problem hiding this comment.
Scenario 2: The response that comes back from imgsrv with the "No Download Found" message doesn't include a current_page, so I added that to an additional conditional. Under these conditions, there will be an error message in the modal and a matomo error event logged.
| } | ||
| if (numAttempts > 100) { | ||
| status.error = true; | ||
| if (numAttempts > 5) { |
There was a problem hiding this comment.
Scenario 3: Changed this from 100 to 5 attempts and replaced the bogus status.error to use the new progressError conditional in the try/catch block.
| HT.live.announce(errorMessage.replace(/<\/?[^>]+(>|$)/g, "")); | ||
| downloadInProgress = false; | ||
| _mtm.push({'event': 'pt-large-download-error', 'downloadUrl': `${requestUrl.toString()}`}); | ||
| _mtm.push({'event': 'pt-download-error', 'errorType': 'callback script error', 'downloadUrl': `${requestUrl.toString()}`}); |
There was a problem hiding this comment.
Update the original matomo custom event error handling to be more specific to the situation it's logging.
moseshll
left a comment
moseshll
left a comment
There was a problem hiding this comment.
Behavior on dev-3 exactly as described. I look forward to getting to the bottom of some of the imgsrv shenanigans. APPROVE
2 participants
There is some kind of bug causing download errors in page turner, and the error handling I recently added didn't account for all the ways imgsrv would/would not send data back about those types of errors. This PR addresses the new error states that I'm aware of now.
All of the errors we can catch in the front-end are larger/"callback"-style downloads. The small downloads are handled completely by imgsrv/the browser. All of the new error handling is related to download progress and calls to
/imgsrv/download-status.Three new scenarios I accounted for:
imgsrvofEOTorDONEto show a message that the download is complete. I found that theDONEstatus is also sent back fromimgsrvwhen "No Download Found"... which is the opposite of the download being complete. The correctDONEstatus is always accompanied by acurrent_pageof-1, so I added that to the "ready for download" conditional.imgsrvwith the "No Download Found" message doesn't include acurrent_page, so I added that to a new conditional. Under these conditions, there will be an error message in the modal and a matomo error event logged.imgsrvand then sets some error state... but the error state didn't actually do anything. Also the number of attempts was 100 and that's just way too many. I updated the conditional to check for 5 attempts (the attempt number goes back to0every time progress is updated, so this block will only be triggered if progress isn't continuing as it should. I tested 10 attempts and it was painfully long. I tried 5 attempts with several high-resolution TIFF downloads and never had an issue with timeout, so I think this is safe). After 5 attempts, it cancels the download (sends theSTOPstatus to/imgsrv/download-status), updates the UI with an error message for the user, and logs a custom error event in matomo.I also rearranged
cancelDownload()so I could pass a boolean value for whether or not to close the modal when the download is cancelled viacallback().The matomo tags are working
testing
This is staged on dev-3. I recommend using this volume that has a error-prone first scan/seq/page to test: https://dev-3.babel.hathitrust.org/cgi/pt?id=mdp.39015082631287&seq=1