-
-
Notifications
You must be signed in to change notification settings - Fork 644
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
Improve startup error handling and reporting for plugins #2092
Comments
in case they aren't existent and don't mark errors to do so as non-fatal. The latter masks the underlying cause when e.g. the `.cache` folder is, for some reason, not writable by zellij (See zellij-org#2092), whereas the former fixes problems arising from the user having purged their .cache/zellij folder entirely.
@alaricljs I'm moving your comment over here so we can discuss your suggestions better. First: Thanks for raising this issue! I had a look at the code and you're totally right. The error is being recognized, but the wrong error is reported to the user. I've already changed that in my development version so the situation will now be much clearer to begin with. About the logfile: I have rewritten the panic message to include this bit of information, it now looks like this:
Do you think this is an improvement over the previous situation? Would you like to see something else as part of the panic message, any additional information we may give to users? About the backtrace: We are aware of this problem and looking for a way to fix it. |
Hey @har7an, looks good and I can't think of anything else that would have been helpful. |
in case they aren't existent and don't mark errors to do so as non-fatal. The latter masks the underlying cause when e.g. the `.cache` folder is, for some reason, not writable by zellij (See zellij-org#2092), whereas the former fixes problems arising from the user having purged their .cache/zellij folder entirely.
* server/plugins: Always recreate plugin folders in case they aren't existent and don't mark errors to do so as non-fatal. The latter masks the underlying cause when e.g. the `.cache` folder is, for some reason, not writable by zellij (See #2092), whereas the former fixes problems arising from the user having purged their .cache/zellij folder entirely. * utils/errors: Rewrite panic message * changelog: Add PR #2093
Moved from #1753:
I'd like to call out an example of how error handling could be improved that is easily reproduced.
I recently messed with my filesystem with specific goals in mind and a side effect that I missed was my user's .cache directory getting owned by root. Everything I previously used could still function since those .cache artifacts already existed and were still owned by me. zellij was the first new thing I tried since this mistake.
When starting zellij for the first time it crashed with a pretty verbose file not found and permission denied error but no specifics as to the file. I then tried the recommended RUST env var to get more info, but the backtrace was unusable as it was all
<unknown>
entries.The only reason I found /tmp/zellij-1000/zellig-log was because I also tried strace against zellij. That log is the only place I got usable info to solve my problem as it specifically stated
failed to create datadir in ".../.cache/..."
. So the quick and easy improvement is to mention the log file in the error messages. The other improvement would be getting the same information that's in the log file into the error message that's displayed to the user.Originally posted by @alaricljs in #1753 (comment)
The text was updated successfully, but these errors were encountered: