-
-
Notifications
You must be signed in to change notification settings - Fork 346
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
[Feature] Display Underlying Errors #3209
Comments
Please fill out the issue template; it has important fields such as "CKAN Version": This sounds like a duplicate of an issue we fixed in v1.29.0 (specifically in #3164). If you're on an older version, the advice would be to upgrade. |
@HebaruSan Thanks for your response, I followed the template that the admins of this repo currently have configured as their desired issue template: I will verify I'm on current version of CKAN and followup. |
@AaronLS you're talking to one of the admins of this repo, and we set that one up for features. You're reporting a bug. Please click the link I gave you. |
@HebaruSan My apologies but I wouldn't have any way of knowing that the behavior is a bug. Had I posted it as a bug, a developer could easily argue my request for additional error details was a feature request, as I'm requesting an enhancement to error reporting. It seemed the behavior I observed was intentional, as I looked around at similar posts about this error and I saw alot of people responding along the lines of "This error could mean many things" which indicates to me its normal for this error to occur by itself. |
Problem
The error "Error during installation!" doesn't provide any indication of what the underlying issue is, which provides no self-diagnostic or targetted troubleshooting path
Suggestion
Include the underlying error. For example, I've seen it said that CKAN will fail if it attempts to overwrite an existing file. It should communicate what file it was attempting to write when it failed, and what the underlying error was.
It's not possible to diagnose the underlying issue if errors are hidden behind a generic "Error during installation!" message.
This error handling pattern of hiding the true error behind a generic message only makes sense on servers where you're concerned about revealing sensitive information in errors to users. In the context of a desktop application, it's better to provide more error detail. Even if maybe some users won't understand the details, it empowers them to take that information and get assistance from others.
Take for example:
Did the error occur during the HTTPS request to retrieve the zip? If so what was the error and or HTTP response failure code?
Did the error occur during the file write operation of the ZIP following the download?
Did the error occur during the file write operation when installing the individual files from the ZIP?
What was the underlying error? Bubbling up the real error would reveal a possible wide range of issues including connectivity issues, file already existing, permission issues, issues with a corrupt zip, etc.
Now you might look at this example and response "Well in this case the download would have succeeded and the error means something failed during installation, and you should go through article X on cleaning/validating your installation..." which misses the point of this error report.
I'm not requesting assistance with troubleshooting the above error. I'm pointing out that users would have the ability to self-diagnose/troubleshoot with more error details or some way to turn on verbose error messaging.
The text was updated successfully, but these errors were encountered: