-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Render processing view for stalled uploads #1102
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes good sense to me!
Searching through the code, it looks like Transcripts and Images both use basically identical retry logic to this. Can we port this to those places as well?
config/locales/en.yml
Outdated
@@ -649,6 +649,7 @@ en: | |||
title: MP3 Not Provided | |||
processing: | |||
hint: Processing | |||
still_processing: Processing is taking longer than expected. Thank you for waiting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW: I prefer the term "patience" over "waiting", ie: "thank you for your patience"... Throw in a llittle "Ope" and we might even get the user to chuckle in another wise frustrating moment.
I suggest:
"Ope, file processing is taking longer than expected - you can continue waiting or retry"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:+3: nice. The spinner being active really conveys that processing stalled, and it's not as angry as landing in error state.
resolves #1094
This PR solves a "hidden timeout" issue users were experiencing, by rendering a "still processing" message for "stalled" uploads. The solution i chose to solve for this was to opt for rendering the
_processing
partial instead of the_error
partial for theupload_stalled?
user conditional flow. I did this because i saw that the only difference betweenupload_processing?
andupload_stalled?
was theretryable
condition. Therefore, a "stalled" upload should still be processing. A side benefit to using the_processing
partial is that it continually polls the server, whereas the_error
partial does not; if a "stalled" upload eventually completed, the_error
view wouldn't refresh on its own to a_complete
view, whereas the_processing
view does.Within the
_processing
partial, i added theretry
button that is conditionally present in the_error
partial, as well as a small (conditional) message underneath the field that notifies the user if the processing is taking longer than expected. This way, we keep the functionality for a user to choose to retry.@cavis for functional review
@brandonhundt for language review